Shared context models for block partition signaling

Abstract

A context for a current block is determined. The current block has a block size and is partitioned into sub-blocks. The block size is mapped to a context group using a block size map. A probability model is selected from a probability table based on the context and the context group. A syntax element related to partitioning of the current block is entropy coded using the probability model. The context may be determined based on a left neighboring block and an above neighboring block of the current block. Determining the context may include calculating a context value based on whether the left neighboring block has a same size as the current block and whether the above neighboring block has a same size as the current block, and combining the context value with a context group identifier using a predefined offset value.

Description

SHARED CONTEXT MODELS FOR BLOCK PARTITION SIGNALINGCROSS REFERENCE TO RELATED APPLICATIONS

[0001] This application claims priority to and the benefit of U.S. Provisional Patent Application Serial No. 63 / 673,955, filed July 22, 2024, the entire disclosure of which is incorporated herein by reference.BACKGROUND

[0002] Digital video streams may represent video using a sequence of frames or still images. Digital video can be used for various applications including, for example, video conferencing, high definition video entertainment, video advertisements, or sharing of usergenerated videos. A digital video stream can contain a large amount of data and consume a significant amount of computing or communication resources of a computing device for processing, transmission, or storage of the video data. Various approaches have been proposed to reduce the amount of data in video streams, including encoding or decoding techniques.SUMMARY

[0003] One aspect of the disclosed implementations relates to a method that includes determining a context for a current block, the current block having a block size and being partitioned into sub-blocks; mapping the block size to a context group using a block size map; selecting a probability model from a probability table based on the context and the context group; and entropy coding a syntax element related to partitioning of the current block using the probability model.

[0004] One aspect of the disclosed implementations relates to the method, where the context is determined based on a left neighboring block and an above neighboring block of the current block.

[0005] One aspect of the disclosed implementations relates to the method, where determining the context includes: calculating a context value based on whether the left neighboring block has a same size as the current block and whether the above neighboring block has a same size as the current block; and combining the context value with a context group identifier using a predefined offset value.

[0006] One aspect of the disclosed implementations relates to the method, where the block size map includes entries that map multiple block sizes of possible block sizes of the current block to a single context group.

[0007] One aspect of the disclosed implementations relates to the method, where the context group is identified using an index into the block size map.

[0008] One aspect of the disclosed implementations relates to the method, where the syntax element includes a flag that indicates whether the current block is partitioned according to one of a plurality of horizontal partition types and, when so partitioned, identifies which horizontal partition type is used.

[0009] One aspect of the disclosed implementations relates to the method, where the syntax element includes a binary flag that indicates whether the current block is partitioned according to an uneven four-way partition.

[0010] One aspect of the disclosed implementations relates to the method, where the syntax element includes a field that has two bits and identifies which of four predefined uneven four-way partitions is used to partition the current block.

[0011] One aspect of the disclosed implementations relates to the method, where the syntax element indicates whether the current block is partitioned horizontally or vertically, and wherein entropy coding the syntax element is performed using a context model selected based on the block size independent of the block size map.

[0012] One aspect of the disclosed implementations relates to the method, where entropy coding the syntax element related to the partitioning of the current block using the probability model includes: decoding the syntax element from a compressed bitstream.

[0013] These and other aspects of the present disclosure are disclosed in the following detailed description of the implementations, the appended claims and the accompanying figures. It will be appreciated that aspects can be implemented in any convenient form. For example, aspects may be implemented by appropriate computer programs which may be carried on appropriate carrier media which may be tangible carrier media (e.g. disks) or intangible carrier media (e.g. communications signals). Aspects may also be implemented using suitable apparatus which may take the form of programmable computers running computer programs arranged to implement the methods and / or techniques disclosed herein. Aspects can be combined such that features described in the context of one aspect may be implemented in another aspect.BRIEF DESCRIPTION OF THE DRAWINGS

[0014] The description herein refers to the accompanying drawings described below, wherein like reference numerals refer to like parts throughout the several views.

[0015] FIG. 1 is a schematic of a video encoding and decoding system.

[0016] FIG. 2 is a block diagram of an example of a computing device that can implement a transmitting station or a receiving station.

[0017] FIG. 3 is a diagram of a typical video stream to be encoded and subsequently decoded.

[0018] FIG. 4 is a block diagram of an encoder according to implementations of this disclosure.

[0019] FIG. 5 is a block diagram of a decoder according to implementations of this disclosure.

[0020] FIG. 6 is an illustration of examples of portions of a video frame.

[0021] FIG. 7 illustrates an example of block partitions.

[0022] FIG. 8 is a block diagram illustrating an example of selecting a probability model for coding a partitioning-related syntax element.

[0023] FIG. 9 illustrates an example of a block size map.

[0024] FIG. 10 is a flowchart of a technique for coding a partitioning of a current block.DETAIEED DESCRIPTION

[0025] Video compression schemes may include breaking respective images, or frames, of a video stream into smaller portions, such as coding tree units (CTUs). A compressed bitstream can be generated using techniques to limit the information included for respective CTUs. The bitstream can be decoded to re-create the source frames from the limited information. Encoding CTUs to or decoding CTUs from a bitstream can include predicting the values of pixels or coding units (CUs) based on similarities with other pixels or CUs in the same frame which have already been coded. Coding units may include luminance and chrominance components that are processed for encoding and decoding.

[0026] As mentioned, a CU (also referred to herein as a block, which may be the luminance component thereof) can be further partitioned into sub-CUs (or sub-blocks). An encoder determines the partitioning (e.g., how a block is partitioned), such as based on ratedistortion analysis or some other criteria, and communicates the partitioning, such as via a compressed bitstream, to a decoder. The partitioning is communicated via one or more syntax elements that may be entropy coded.

[0027] Entropy coding, such as arithmetic coding, is a technique for “lossless” coding that relies upon probability models (i.e., probability distributions) to model the distribution of values occurring in the data. That is, entropy coding a value (e.g., a syntax element) involves the selection of a context model (also referred to as a probability context model, or probability model), which provides estimates of conditional probabilities for coding the value. Additional information may be used as the context for selecting a context model. By using probability models based on a measured or estimated distribution of values, entropy coding can reduce the number of bits required to represent data (e.g., image, video data, or syntax elements) close to a theoretical minimum. In practice, the actual reduction in the number of bits required to represent video data can be a function of the accuracy of the probability model, the length of the coded data, and the precision of the arithmetic operations used. As such, the efficiency of entropy coding is directly related to the selected probability model for coding a syntax element. A context, as used herein, can be, or can be a parameter in, a lossless (entropy) coding process. A context can be any parameter or method that affects probability estimation for entropy coding.

[0028] In conventional codecs, partition-related syntax elements for each block size (from the smallest (e.g., 4 x 4) to the largest (e.g., 256 x 256)) are often associated with distinct probability distributions (context models). This size-specific modeling conditions partition signaling on block-size statistics, thereby preserving high coding efficiency for partition decisions.

[0029] However, such conventional configurations are not optimal, especially for hardware-implemented codecs, due to the extensive hardware and storage resources required to store all the probability distributions. Each unique context model is typically stored and managed separately, leading to significant increases in memory usage and computational overhead. For instance, the need to maintain distinct context models for each block size results in an unacceptable growth of required storage as more block sizes are supported, from 4x4 up to 256x256 and beyond. This can be particularly problematic in devices with limited storage capacity and computational power, such as mobile devices or embedded systems, where efficiency and resource management are critical.

[0030] Implementations according to this disclosure reduce the number of context models used in signaling (e.g., encoding and decoding) syntax elements related to block partitioning (i.e., partitioning-related syntax elements). Context models used for block partition signaling can be shared among blocks of different sizes. Two blocks are deemed “similar” when they map to the same entry in the BSIZE_MAP (see FIG. 9); that is, when the encoder or decoderelects to share a common context group for those block sizes. This mapping may typically limit the ratio of their widths (or heights) to about 2: 1 and the ratio of their total pixel counts to within roughly 4:1. Accordingly, blocks that map to the same context-group identifier are treated as similar for context selection.

[0031] By consolidating multiple block sizes into shared context groups, the overall number of context models required is significantly decreased. This reduction not only minimizes the storage and computational demands but also maintains the high coding efficiency and compression performance necessary for effective video encoding. While having different context models per block size may result in more optimal coding performance, sharing of context models for different block sizes strikes a balance between compression performance and hardware costs. The shared context models may be empirically derived to ensure optimal grouping, providing a balanced trade-off between resource utilization and encoding accuracy.

[0032] Further details of techniques for shared context models for block partition signaling are described herein with initial reference to a system in which such techniques can be implemented. FIG. 1 is a schematic of a video encoding and decoding system 100. A transmitting station 102 can be, for example, a computer having an internal configuration of hardware such as that described in FIG. 2. However, other implementations of the transmitting station 102 are possible. For example, the processing of the transmitting station 102 can be distributed among multiple devices.

[0033] A network 104 can connect the transmitting station 102 and a receiving station 106 for encoding and decoding of the video stream. Specifically, the video stream can be encoded in the transmitting station 102, and the encoded video stream can be decoded in the receiving station 106. The network 104 can be, for example, the Internet. The network 104 can also be a local area network (LAN), wide area network (WAN), virtual private network (VPN), cellular telephone network, or any other means of transferring the video stream from the transmitting station 102 to, in this example, the receiving station 106.

[0034] The receiving station 106, in one example, can be a computer having an internal configuration of hardware such as that described in FIG. 2. However, other suitable implementations of the receiving station 106 are possible. For example, the processing of the receiving station 106 can be distributed among multiple devices.

[0035] Other implementations of the video encoding and decoding system 100 are possible. For example, an implementation can omit the network 104. In another implementation, a video stream can be encoded and then stored for transmission at a latertime to the receiving station 106 or any other device having memory. In one implementation, the receiving station 106 receives (e.g., via the network 104, a computer bus, and / or some communication pathway) the encoded video stream and stores the video stream for later decoding. In an example implementation, a real-time transport protocol (RTP) is used for transmission of the encoded video over the network 104. In another implementation, a transport protocol other than RTP may be used (e.g., a Hypertext Transfer Protocol-based (HTTP-based) video streaming protocol).

[0036] When used in a video conferencing system, for example, the transmitting station 102 and / or the receiving station 106 may include the ability to both encode and decode a video stream as described below. For example, the receiving station 106 could be a video conference participant who receives a compressed bitstream from a video conference server (e.g., the transmitting station 102) to decode and view and further encodes and transmits his or her own video bitstream to the video conference server for decoding and viewing by other participants.

[0037] FIG. 2 is a block diagram of an example of a computing device 200 that can implement a transmitting station or a receiving station. For example, the computing device 200 can implement one or both of the transmitting station 102 and the receiving station 106 of FIG. 1. The computing device 200 can be in the form of a computing system including multiple computing devices, or in the form of one computing device, for example, a mobile phone, a tablet computer, a laptop computer, a notebook computer, a desktop computer, and the like.

[0038] A processor 202 in the computing device 200 can be a conventional central processing unit. Alternatively, the processor 202 can be another type of device, or multiple devices, capable of manipulating or processing information now existing or hereafter developed. For example, although the disclosed implementations can be practiced with one processor as shown (e.g., the processor 202), advantages in speed and efficiency can be achieved by using more than one processor.

[0039] A memory 204 in computing device 200 can be a read only memory (ROM) device or a random access memory (RAM) device in an implementation. However, other suitable types of storage device can be used as the memory 204. The memory 204 can include code and data 206 that is accessed by the processor 202 using a bus 212. The memory 204 can further include an operating system 208 and application programs 210, the application programs 210 including at least one program that permits the processor 202 to perform the techniques described herein. For example, the application programs 210 can includeapplications 1 through N, which further include a video coding application that performs the techniques described herein. The computing device 200 can also include a secondary storage 214, which can, for example, be a memory card used with a mobile computing device.Because the video communication sessions may contain a significant amount of information, they can be stored in whole or in part in the secondary storage 214 and loaded into the memory 204 as needed for processing.

[0040] The computing device 200 can also include one or more output devices, such as a display 218. The display 218 may be, in one example, a touch sensitive display that combines a display with a touch sensitive element that is operable to sense touch inputs. The display 218 can be coupled to the processor 202 via the bus 212. Other output devices that permit a user to program or otherwise use the computing device 200 can be provided in addition to or as an alternative to the display 218. When the output device is or includes a display, the display can be implemented in various ways, including by a liquid crystal display (LCD), a cathode-ray tube (CRT) display, or a light emitting diode (LED) display, such as an organic LED (OLED) display.

[0041] The computing device 200 can also include or be in communication with an image-sensing device 220, for example, a camera, or any other image-sensing device 220 now existing or hereafter developed that can sense an image such as the image of a user operating the computing device 200. The image-sensing device 220 can be positioned such that it is directed toward the user operating the computing device 200. In an example, the position and optical axis of the image-sensing device 220 can be configured such that the field of vision includes an area that is directly adjacent to the display 218 and from which the display 218 is visible.

[0042] The computing device 200 can also include or be in communication with a soundsensing device 222, for example, a microphone, or any other sound-sensing device now existing or hereafter developed that can sense sounds near the computing device 200. The sound-sensing device 222 can be positioned such that it is directed toward the user operating the computing device 200 and can be configured to receive sounds, for example, speech or other utterances, made by the user while the user operates the computing device 200.

[0043] Although FIG. 2 depicts the processor 202 and the memory 204 of the computing device 200 as being integrated into one unit, other configurations can be utilized. The operations of the processor 202 can be distributed across multiple machines (wherein individual machines can have one or more processors) that can be coupled directly or across a local area or other network. The memory 204 can be distributed across multiple machinessuch as a network-based memory or memory in multiple machines performing the operations of the computing device 200. Although depicted here as one bus, the bus 212 of the computing device 200 can be composed of multiple buses. Further, the secondary storage 214 can be directly coupled to the other components of the computing device 200 or can be accessed via a network and can comprise an integrated unit such as a memory card or multiple units such as multiple memory cards. The computing device 200 can thus be implemented in a wide variety of configurations.

[0044] In some implementations, the code and data 206, the operating system 208, and the application programs 210 may be stored on a non-transitory computer-readable storage medium. The term “non-transitory” excludes transitory signals and refers to media such as hard drives, flash memory, ROM, and other physical storage devices capable of storing executable instructions. Such a non-transitory computer-readable storage medium may contain instructions that, when executed by the processor 202, cause the computing device 200 to perform any of the methods or processes described herein, including reference frame motion field selection for wedge mode blocks. The secondary storage 214 is a non-transitory computer-readable storage medium that can store code and data, including machine-readable instructions that, when executed by the processor 202, cause the computing device 200 to perform one or more of the techniques described herein.

[0045] FIG. 3 is a diagram of an example of a video stream 300 to be encoded and subsequently decoded. The video stream 300 includes a video sequence 302. At the next level, the video sequence 302 includes a number of adjacent frames 304. While three frames are depicted as the adjacent frames 304, the video sequence 302 can include any number of adjacent frames 304. The adjacent frames 304 can then be further subdivided into individual frames, for example, a frame 306. At the next level, the frame 306 can be divided into a series of planes or segments 308. The segments 308 can be subsets of frames that permit parallel processing, for example. The segments 308 can also be subsets of frames that can separate the video data into separate colors. For example, a frame 306 of color video data can include a luminance plane and two chrominance planes. The segments 308 may be sampled at different resolutions.

[0046] Whether or not the frame 306 is divided into segments 308, the frame 306 may be further subdivided into blocks 310, which can contain data corresponding to, for example, 16x16 pixels in the frame 306. The blocks 310 can also be arranged to include data from one or more segments 308 of pixel data. The blocks 310 can also be of any other suitable sizesuch as 4x4 pixels, 8x8 pixels, 16x8 pixels, 8x16 pixels, 16x16 pixels, or larger. Unless otherwise noted, the terms block and macroblock are used interchangeably herein.

[0047] FIG. 4 is a block diagram of an encoder 400 according to implementations of this disclosure. The encoder 400 can be implemented, as described above, in the transmitting station 102, such as by providing a computer software program stored in memory, for example, the memory 204. The computer software program can include machine instructions that, when executed by a processor such as the processor 202, cause the transmitting station 102 to encode video data in the manner described in FIG. 4. The encoder 400 can also be implemented as specialized hardware included in, for example, the transmitting station 102. In some implementations, the encoder 400 is a hardware encoder.

[0048] The encoder 400 has the following stages to perform the various functions in a forward path (shown by the solid connection lines) to produce a compressed bitstream 420 (e.g., encoded bitstream) using the video stream 300 as input: an intra / inter prediction stage 402, a transform stage 404, a quantization stage 406, and an entropy encoding stage 408. The encoder 400 may also include a reconstruction path (shown by the dotted connection lines) to reconstruct a frame for encoding of future blocks. In FIG. 4, the encoder 400 has the following stages to perform the various functions in the reconstruction path: a dequantization stage 410, an inverse transform stage 412, a reconstruction stage 414, and a loop filtering stage 416. Other structural variations of the encoder 400 can be used to encode the video stream 300.

[0049] When the video stream 300 is presented for encoding, respective adjacent frames 304, such as the frame 306, can be processed in units of blocks. At the intra / inter prediction stage 402, respective blocks can be encoded using intra-frame prediction (also called intraprediction) or inter- frame prediction (also called inter-prediction). In any case, a prediction block can be formed. In the case of intra-prediction, a prediction block may be formed from samples in the current frame that have been previously encoded and reconstructed. In the case of inter-prediction, a prediction block may be formed from samples in one or more previously constructed reference frames.

[0050] Next, the prediction block can be subtracted from the current block at the intra / inter prediction stage 402 to produce a residual block (also called a residual). The transform stage 404 transforms the residual into transform coefficients in, for example, the frequency domain using block-based transforms. The quantization stage 406 converts the transform coefficients into discrete quantum values, which are referred to as quantizedtransform coefficients, using a quantizer value or a quantization level. For example, the transform coefficients may be divided by the quantizer value and truncated.

[0051] The quantized transform coefficients are then entropy encoded by the entropy encoding stage 408. The entropy-encoded coefficients, together with other information used to decode the block (which may include, for example, syntax elements such as used to indicate the type of prediction used, transform type, motion vectors, a quantizer value, or the like), are then output to the compressed bitstream 420. The compressed bitstream 420 can be formatted using various techniques, such as variable length coding (VLC) or arithmetic coding. The compressed bitstream 420 can also be referred to as an encoded video stream or compressed bitstream, and the terms will be used interchangeably herein.

[0052] The reconstruction path (shown by the dotted connection lines) can be used to ensure that the encoder 400 and a decoder 500 (described below with respect to FIG. 5) use the same reference frames to decode the compressed bitstream 420. The reconstruction path performs functions that are similar to functions that take place during the decoding process (described below with respect to FIG. 5), including dequantizing the quantized transform coefficients at the dequantization stage 410 and inverse transforming the dequantized transform coefficients at the inverse transform stage 412 to produce a derivative residual block (also called a derivative residual). At the reconstruction stage 414, the prediction block that was predicted at the intra / inter prediction stage 402 can be added to the derivative residual to create a reconstructed block. The loop filtering stage 416 can be applied to the reconstructed block to reduce distortion such as blocking artifacts.

[0053] Other variations of the encoder 400 can be used to encode the compressed bitstream 420. In some implementations, a non-transform based encoder can quantize the residual signal directly without the transform stage 404 for certain blocks or frames. In some implementations, an encoder can have the quantization stage 406 and the dequantization stage 410 combined in a common stage.

[0054] FIG. 5 is a block diagram of a decoder 500 according to implementations of this disclosure. The decoder 500 can be implemented in the receiving station 106, for example, by providing a computer software program stored in the memory 204. The computer software program can include machine instructions that, when executed by a processor such as the processor 202, cause the receiving station 106 to decode video data in the manner described in FIG. 5. The decoder 500 can also be implemented in hardware included in, for example, the transmitting station 102 or the receiving station 106.

[0055] The decoder 500, similar to the reconstruction path of the encoder 400 discussed above, includes in one example the following stages to perform various functions to produce an output video stream 516 from the compressed bitstream 420: an entropy decoding stage 502, a dequantization stage 504, an inverse transform stage 506, an intra / inter prediction stage 508, a reconstruction stage 510, a loop filtering stage 512, and a deblocking filtering stage 514. Other structural variations of the decoder 500 can be used to decode the compressed bitstream 420.

[0056] When the compressed bitstream 420 is presented for decoding, the data elements within the compressed bitstream 420 can be decoded by the entropy decoding stage 502 to produce a set of quantized transform coefficients. The dequantization stage 504 dequantizes the quantized transform coefficients (e.g., by multiplying the quantized transform coefficients by the quantizer value), and the inverse transform stage 506 inverse transforms the dequantized transform coefficients to produce a derivative residual that can be identical to that created by the inverse transform stage 412 in the encoder 400. Using header information decoded from the compressed bitstream 420, the decoder 500 can use the intra / inter prediction stage 508 to create the same prediction block as was created in the encoder 400 (e.g., at the intra / inter prediction stage 402).

[0057] At the reconstruction stage 510, the prediction block can be added to the derivative residual to create a reconstructed block. The loop filtering stage 512 can be applied to the reconstructed block to reduce blocking artifacts. Other filtering can be applied to the reconstructed block. In this example, the deblocking filtering stage 514 is applied to the reconstructed block to reduce blocking distortion, and the result is output as the output video stream 516. The output video stream 516 can also be referred to as a decoded video stream, and the terms will be used interchangeably herein. Other variations of the decoder 500 can be used to decode the compressed bitstream 420. In some implementations, the decoder 500 can produce the output video stream 516 without the deblocking filtering stage 514.

[0058] FIG. 6 is an illustration of examples of portions of a video frame 600, which may, for example, be the frame 306 shown in FIG. 3. The video frame 600 includes a number of 64x64 CTUs, such as four 64x64 CTUs 610 in two rows and two columns in a matrix or Cartesian plane, as shown. Each 64x64 CTU 610 may include up to four 32x32 CUs 620. Each 32x32 CU 620 may include up to four 16x16 CUs 630. Each 16x16 CU 630 may include up to four 8x8 CUs 640. Each 8x8 CU 640 may include up to four 4x4 CUs 650. Each of the 4x4 CUs 650 may include 16 pixels, which may be represented in four rows and four columns in each respective CU in the Cartesian plane or matrix.

[0059] In some implementations, the video frame 600 may include CTUs larger than 64x64 and / or CUs smaller than 4x4. Subject to features within the video frame 600 and / or other criteria, the video frame 600 may be partitioned into various arrangements. Although one arrangement of CUs is shown, any arrangement may be used. Although FIG. 6 shows NxN CTUs and CUs, in some implementations, NxM CTUs and / or CUs may be used, wherein N and M are different numbers. For example, 32x64 CTUs, 64x32 CTUs, 16x32 CUs, 32x16 CUs, or any other size may be used. In some implementations, Nx2N CTUs or CUs, 2NxN CTUs or CUs, or a combination thereof, may be used.

[0060] The pixels may include information representing an image captured in the video frame 600, such as luminance information, color information, and location information. In some implementations, a block, such as a 16x16 pixel block as shown, may include a luminance block 660, which may include luminance pixels 662; and two chrominance blocks 670, 680, such as a U or Cb chrominance block 670, and a V or Cr chrominance block 680. The chrominance blocks 670, 680 may include chrominance pixels 690. For example, the luminance block 660 may include 16x16 luminance pixels 662 and each chrominance block 670, 680 may include 8x8 chrominance pixels 690 as shown.

[0061] In some implementations, coding the video frame 600 may include ordered blocklevel coding. Ordered block-level coding may include coding CUs of the video frame 600 in an order, such as raster-scan order, wherein CUs may be identified and processed starting with a CTU in the upper left comer of the video frame 600, or portion of the video frame 600, and proceeding along rows from left to right and from the top row to the bottom row, identifying each CU in turn for processing. For example, the 64x64 CTU in the top row and left column of the video frame 600 may be the first CTU coded and the 64x64 CTU immediately to the right of the first CTU may be the second CTU coded. The second row from the top may be the second row coded, such that the 64x64 CTU in the left column of the second row may be coded after the 64x64 CTU in the rightmost column of the first row.

[0062] In some implementations, coding a CTU of the video frame 600 may include using quad-tree coding, which may include coding smaller CUs within a CTU in raster-scan order. For example, the 64x64 CTU shown in the bottom left corner of the portion of the video frame 600 may be coded using quad-tree coding wherein the top left 32x32 CU may be coded, then the top right 32x32 CU may be coded, then the bottom left 32x32 CU may be coded, and then the bottom right 32x32 CU may be coded. Each 32x32 CU may be coded using quad-tree coding wherein the top left 16x16 CU may be coded, then the top right 16x16 CU may be coded, then the bottom left 16x16 CU may be coded, and then the bottomright 16x16 CU may be coded. Each 16x16 CU may be coded using quad-tree coding wherein the top left 8x8 CU may be coded, then the top right 8x8 CU may be coded, then the bottom left 8x8 CU may be coded, and then the bottom right 8x8 CU may be coded. Each 8x8 CU may be coded using quad-tree coding wherein the top left 4x4 CU may be coded, then the top right 4x4 CU may be coded, then the bottom left 4x4 CU may be coded, and then the bottom right 4x4 CU may be coded. In some implementations, 8x8 CUs may be omitted for a 16x16 CU, and the 16x16 CU may be coded using quad-tree coding wherein the top left 4x4 CU may be coded, then the other 4x4 CUs in the 16x16 CU may be coded in raster- scan order.

[0063] In some implementations, coding the video frame 600 may include encoding the information included in the original version of the image or video frame by, for example, omitting some of the information from that original version of the image or video frame from a corresponding encoded image or encoded video frame. For example, the coding may include reducing spectral redundancy, reducing spatial redundancy, or a combination thereof. Reducing spectral redundancy may include using a color model based on a luminance component (Y) and two chrominance components (U and V or Cb and Cr), which may be referred to as the YUV or YCbCr color model, or color space. Using the YUV color model may include using a relatively large amount of information to represent the luminance component of a portion of the video frame 600, and using a relatively small amount of information to represent each corresponding chrominance component for the portion of the video frame 600. For example, a portion of the video frame 600 may be represented by a high-resolution luminance component, which may include a 16x16 block of luma samples, and by two lower resolution chrominance components, each of which represents the portion of the image as an 8x8 block of chroma samples. A sample may indicate a value, for example, a value in the range from 0 to 255, and may be stored or transmitted using, for example, eight bits. Although this disclosure is described in reference to the YUV color model, another color model may be used. Reducing spatial redundancy may include transforming a CU into the frequency domain using, for example, a discrete cosine transform. For example, a unit of an encoder may perform a discrete cosine transform using transform coefficient values based on spatial frequency.Although described herein with reference to matrix or Cartesian representation of the video frame 600 for clarity, the video frame 600 may be stored, transmitted, processed, or a combination thereof, in a data structure such that pixel values and / or luma and chroma samples may be efficiently represented for the video frame 600. For example, the video frame600 may be stored, transmitted, processed, or any combination thereof, in a two-dimensional data structure such as a matrix as shown, or in a one-dimensional data structure, such as a vector array. Furthermore, although described herein as showing a chrominance subsampled image where U and V have half the resolution of Y, the video frame 600 may have different configurations for the color channels thereof. For example, referring still to the YUV color model, full resolution may be used for all color channels of the video frame 600. In another example, a color space other than the YUV color model may be used to represent the resolution of color channels of the video frame 600.

[0064] FIG. 7 illustrates an example 700 of block partitions. The example 700 illustrates a block 702 of size NxN that may be partitioned into one of the partitions 704-722. However, the disclosure is not limited to or by any specific partitions described herein. An encoder may determine the partition of the block 702 and signal, in a compressed bitstream, such as the compressed bitstream 420 of FIG. 4, how the block 702 is partitioned. The encoder signals the partition using one or more syntax elements, such as described herein. The decoder reads (e.g., decodes) one or more syntax elements to correspondingly partition the block.

[0065] The partition 704 indicates that the block 702 is not further partitioned. Said another way, the block 702 may be considered to be partitioned into one sub-block that is coextensive with the block 702. The partition 706 indicates that the block 702 is partitioned into four N / 2xN / 2 sub-blocks. The partition 708 indicates that the block 702 is partitioned into two NxN / 2 sub-blocks. The partition 710 indicates that the block 702 is partitioned into two N / 2xN sub-blocks.

[0066] The partition 712 indicates that the block 702 is partitioned in four sub-blocks: a first sub-block 712A of size NxN / 4, a second sub-block 712B of size N / 2xN / 2, a third subblock 712C of size N / 2xN / 2, and a fourth sub-block 712D of size NxN / 4. The partition 714 indicates that the block 702 is partitioned into four sub-blocks: a first sub-block 714A of size N / 4xN, a second sub-block 714B of size N / 2xN / 2, a third sub-block 714C of size N / 2xN / 2, and a fourth sub-block 714D of size N / 4xN.

[0067] The partition 716 indicates that the block 702 is partitioned into four sub-blocks: a first sub-block 716A of size N / 8xN, a second sub-block 716B of size N / 4xN, a third subblock 716C of size N / 2xN, and a fourth sub-block 716D of size N / 8xN. The partition 718 indicates that the block 702 is partitioned into four sub-blocks: a first sub-block 718A of size N / 8xN, a second sub-block 718B of size N / 2xN, a third sub-block 718C of size N / 4xN, and a fourth sub-block 718D of size N / 8xN. The partition 720 indicates that the block 702 is partitioned into four sub-blocks: a first sub-block 720A of size NxN / 8, a second sub-block720B of size NxN / 2, a third sub-block 720C of size NxN / 4, and a fourth sub-block 720D of size NxN / 8. The partition 722 indicates that the block 702 is partitioned into four sub-blocks: a first sub-block 722A of size NxN / 8, a second sub-block 722B of size NxN / 4, a third subblock 722C of size N / 2xN / 2, and a fourth sub-block 722D of size NxN / 8.

[0068] The partition 704 may be referred to as PARTITION_NONE. The partition 706 may be referred to as a PARTITION_SPLIT. The partition 708 may be referred to as PARTITION_HORIZ. The partition 710 may be referred to as PARTITION- VERT. The partition 712 may be referred to as PARTITION_HORIZ_H. The partition 714 may be referred to as PARTITION_VERT_H. The partition 716 may be referred to as PARTITION_HORIZ_4A. The partition 718 may be referred to as PARTITION_HORIZ_4B. The partition 720 may be referred to as PARTITION_VERT_4A. The partition 722 may be referred to as PARTITION_VERT_4B. The partitions 712 and 714 may be referred collectively as the H_PARTITIONS. The partitions 716 through 722 may be referred collectively as the UNEVEN_4_WAY, also referred to as uneven four-way partitions, because they divide the block into four unequally-sized sub-blocks.

[0069] Some of these partitions may not be available for certain block sizes of the block 702. To illustrate, if the block 702 has the smallest possible sub-block size (e.g., 4x4), then it can not be further partitioned. If the block 702 has a larger size, specific partitions may or may not be possible based on other constraints related to the dimensions (e.g., the width and / or height) of the block 702. Any such constraints are not necessary for the understanding of this disclosure and are, therefore, omitted.

[0070] The block partition of the block 702 may be signaled using at least some of the syntax elements: do_split, rect_type, do_ext_partition, do_uneven_4way, and uneven_4way_partition. Collectively, these syntax elements are referred to herein as the partitioning-related syntax elements.

[0071] The syntax element do_split indicates whether the block 702 is to be partitioned. If the value of this syntax element is zero, then no other syntax element is signaled and the partition 704 is assumed. If do_split is non-zero, additional syntax elements may be used to specify the partitioning. The rect_type syntax element can be used to signal one of the partitions 708 (PARTITION_HORIZ) or 710 (PARTITION_VERT). A value of 0 for rect_type may indicate PARTITION_HORIZ, while a value of 1 may indicate PARTITION- VERT.

[0072] While the grouping approach can be applied to the four partitioning-related syntax elements, the rect_type syntax element may use ungrouped context models. Experimentationshows that merging rect_type contexts incurs a measurable coding loss of about 0.1 % BD- Rate. BD-Rate (Bj0ntegaard Delta Rate) is a standardized metric used in video compression research to measure the percentage change in bitrate required to achieve the same video quality when comparing two different encoding methods or codecs. Accordingly, rect_type is encoded or decoded using the context model selected by its native block- size index, independent of the BSIZE_MAP grouping.

[0073] The syntax element do_ext_partition can be signaled to indicate whether the block 702 is partitioned according to one of the H_PARTITIONS, and if so, which one. To illustrate, and without limitation, a value of 0 may indicate that the block 702 is not partitioned according to one of the H_PARTITIONS, a value of 1 may indicate that the block 702 is partitioned according to the partition 712 (PARTITION_HORIZ_H), and a value of 2 may indicate that the block 702 is partitioned according to the partition 714 (PARTITION_VERT_H).

[0074] The syntax element do_uneven_4way can be a binary flag that indicates whether the block 702 is partitioned according to one of the UNEVEN_4_WAY partitions. If the block 702 is partitioned according to one of the UNEVEN_4_WAY partitions, then the syntax element uneven_4way_partition_type can be a 2-bit syntax element that indicates one of the partitions 716-722. For instance, a value of 0 for uneven_4way_partition_type may indicate partition 716 (PARTITION_HORIZ_4A), a value of 1 may indicate partition 718 (PARTITION_HORIZ_4B), a value of 2 may indicate partition 720 (PARTITION_VERT_4A), and a value of 3 may indicate partition 722 (PARTITION_VERT_4B) .

[0075] FIG. 8 is a block diagram illustrating an example 800 of selecting a probability model for coding a partitioning-related syntax element. As already mentioned, coding (i.e., entropy coding) involves selecting a probability model. Each partitioning-related syntax element may be associated with one or more probability models. The number of probability models associated with a syntax element can be related to or based on the number of possible contexts, such as described herein.

[0076] The example 800 includes a probability model selector 802, which can be implemented by or included in an entropy coding stage. When implemented by an encoder, such as the encoder 400 of FIG. 4, the probability model selector 802 can be implemented by or included in the entropy encoding stage 408; and when implemented by a decoder, such as the decoder 500 of FIG. 5, the probability model selector 802 can be implemented by or included in the entropy decoding stage 502.

[0077] The probability model selector 802 uses a block size map 804, a block size 806, a context 808, and a probability table 810 to output (e.g., select, identify, etc.) a probability model 812, or an indicator thereof, for entropy coding the syntax element. For example, the probability model selector 802 may output an index (e.g., a value for a variable ctx) into the probability table 810. That is, the index is used to identify (e.g., retrieve) the probability model 812 from the probability table 810.

[0078] The block size map 804 provides a mapping between various block sizes and their corresponding groups. This mapping is used to determine which context models can be shared among different block sizes, thereby reducing the total number of required context models.

[0079] FIG. 9 illustrates an example of a block size map 900, which can be the block size map 804. It is noted that the disclosure herein is not limited to or by the specific mappings between block sizes and context groupings of the block size map 900 and other mappings are possible.

[0080] The block size map 900 shows an array BSIZE_MAP that associates different block sizes with context groups. Each entry in the array corresponds to a specific block size, represented by constants such as BLOCK_4X4, BLOCK_8X8, etc. The values in the array are context group identifiers that indicate which context models can be shared among different block sizes. For example, a group of block sizes 902 that includes block size 4x4, 4x8, 8x4, and 8x8 are all mapped to the context group 0, indicating that these block sizes share the same context model. Similarly, a group of block sizes 904 that includes block sizes 8x16, 16x8, and 16x16 are mapped to the context group 6.

[0081] The block size map 900 illustrates that larger blocks such as a block size 906 and larger (e.g., block sizes above 64x64) tend to prefer to have their own context(s) for each bsize (block size). Additionally, the block size map 900 illustrates or reflects the observation that block sizes with 1:4 or 4:1 ratios, such as the block sizes 908 (e.g., 4x16, 16x4, 8x32, 32x8, 16x64, and 64x16), are better coded using respective probability models corresponding to each of the block sizes 908. That is, such block sizes are not grouped with other block sizes for the purpose of probability model selection. However, in an implementation, and to reduce complexity, these block sizes can be grouped into one group. That is, the block sizes 4x16, 16x4, 8x32, 32x8, 16x64, and 64x16 can be mapped to the same group number so that they share the same context(s). In an example, subsets of these block sizes that meet the sizes criteria MxN and NxM can be mapped to the same group. For example, the block sizes 4x16and 16x4 can be mapped to one group; the block sizes 8x32 and 32x8 can be mapped to another group; and the block sizes 16x64, and 64x16 can be mapped to yet another group.

[0082] The use of context groups results in a reduction in the total number of unique context models needed for block partitioning signaling, thereby saving storage and computational resources. The specific mapping of block sizes to context groups, as illustrated in the block size map 900, can vary based on empirical data and optimization criteria specific to the encoding process. The block size map 900, as illustrated, is an example and can be modified to include other block sizes or different context group mappings.

[0083] Referring again to FIG. 8, the block size 806 represents the size of the current block being processed, such as the block 702 of FIG. 7. To be clear, the block size 806 is an indicator or an identifier of the size of the current block. To illustrate, and referring briefly to FIG. 9, values of 0, 9, 14, and 19 of the block size 806 may indicate the block sizes 4x4, 32x32, 128x64, and 4x16, respectively. Different block sizes may be associated with different probability models. The block size 806 (i.e., bsize) is used to identify one or a group of probability models. The block size 806 can be used as an index into the block size map 804. In an example, the probability model selector 802 may receive the width and the height of the current block. In such a case, the probability model selector 802 uses the width and height to derive the block size 806.

[0084] The context 808 can be any context or information usable to refine the selection of the probability model 812, ensuring that the probability model 812 more accurately reflects the local characteristics of the current block being encoded or decoded. In an example, the context 808 can relate or be derived from neighboring blocks of the current block. That is, the context 808 can provide information about neighboring blocks of the current block. The neighboring blocks can be or include at least the above neighboring block and the left neighboring block. The context may be, include, or be related to whether the above neighboring block has the same size as the current block and whether the left neighboring block has the same size as the current block. As such, four different values are possible.

[0085] The probability table 810 stores the probability models or distributions that are used for entropy coding. The probability model selector 802 uses indices or context information to access specific entries in the probability table 810, retrieving the probability models necessary for encoding or decoding the syntax elements associated with block partitioning.

[0086] Table I illustrates an example of a pseudocode implemented by the probability model selector 802 for selecting the probability model 812.TABLE I

[0087] The function partition_plane_context() calculates a context index (ctx) based on the size of a current block, which is then used to select the corresponding probability model from a predefined table. The size of the current block is indicated by the parameter bsize. The context index helps in predicting the partitioning decisions more accurately by considering the neighboring block information. The parameter xd is a pointer to a macroblock structure, which contains information about the current block; and parameters mi_row and mi_col may indicate the horizontal and vertical offsets of the current block within its frame.

[0088] In lines 2 and 3, a helper function f() is called to calculate the context values of the neighboring blocks. The function f() returns values for the context information (left_ctx and above_ctx) for the block located to the left and above the current block, respectively.Left_ctx and above_ctx can each be 0 or 1. The expression (left_ctx * 2 + above_ctx) aggregates the context values from the left and above neighbors. The expression can have one the values 0, 1, 2, or 3. The bsize_map [bsize] retrieves the context group identifier for the current block size from the block size map 804 (i.e., bsize_map). The PARTITION_PLOFFSET is a predefined constant that helps scale the context group identifier appropriately. As the expression (left_ctx * 2 + above_ctx) results in one of four possible values, PARTITION_PLOFFSET is set to 4.

[0089] According to the conventional techniques described above, if there are 25 different possible block sizes and four (e.g., PARTITION_PLOFFSET) possible probability models for each of the block sizes, then a total of 25*4=100 probability models would have to be maintained. However, using, for example, the grouping described with respect to FIGS. 8 and 9, then 16*4=64 probability models need to be maintained.

[0090] To further describe some implementations in greater detail, reference is next made to examples of techniques which may be performed for selecting a probability model for coding a partitioning-related syntax element. FIG. 10 is a flowchart of a technique 1000 for coding a partitioning of a current block. The current block can be the block 702 of FIG. 7. The technique 1000 can be executed using computing devices, such as the systems, hardware, and software described with respect to FIGS. 1-9.

[0091] The technique 1000 can be implemented, for example, as a software program that may be executed by computing devices such as transmitting station 102 or receiving station 106. The software program can include machine-readable instructions that may be stored in a memory such as the memory 204 or the secondary storage 214, and that, when executed by a processor, such as the processor 202, may cause the computing device to perform the technique 1000. The technique 1000 may be implemented in whole or in part in the entropy encoding stage 408 of the encoder 400 of FIG. 4 and / or the entropy decoding stage 502 of the decoder 500 of FIG. 5. When implemented by an encoder, “coding” includes “entropy encoding;” and when implemented by a decoder, “coding” includes “entropy decoding.” The technique 1000 can be implemented using specialized hardware or firmware. Multiple processors, memories, or both, may be used.

[0092] At 1002, a context for a current block is determined. The context can be derived from neighboring blocks, such as the above and left neighboring blocks. As such, the context can be determined based on a left neighboring block and an above neighboring block of the current block. The context can be or include information about whether each of these neighboring blocks has the same size as the current block. This context helps refine the selection of the probability model, ensuring that it accurately reflects the local characteristics of the block being processed.

[0093] At 1004, the block size is mapped to a context group using a block size map. The block size map provides a mapping between different block sizes and context groups, allowing multiple block sizes to share the same context model. The block size map includes entries that map multiple block sizes of possible block sizes of the current block to a single context group. The context group can be identified using an index into the block size map. This mapping helps reduce the total number of unique context models required for partitioning decisions.

[0094] At 1006, a probability model is selected from a probability table based on the context and the context group. The probability table stores various probability models, and the selection is made by using an index derived from the context and the context group. Thisensures that the most appropriate probability model is used for entropy coding the partitioning-related syntax elements.

[0095] At 1008, a syntax element related to the partitioning of the current block is entropy coded using the selected probability model. The syntax element can include information such as partition flags, split types, or other partitioning indicators. The syntax element can be a partition flag indicating whether the current block is further partitioned. The syntax element can include a flag that indicates whether the current block is partitioned according to one of a plurality of horizontal partition types and, when so partitioned, identifies which horizontal partition type is used.

[0096] The syntax element can be a split type indicating a type of partitioning of the current block. The syntax element can include a binary flag that indicates whether the current block is partitioned according to an uneven four-way partition. The syntax element can include a field that has two bits and identifies which of four predefined uneven four-way partitions is used to partition the current block. The syntax element may indicate whether the current block is partitioned horizontally or vertically, and entropy coding the syntax element can be performed using a context model selected based on the block size independent of the block size map. The syntax element can be any other partitioning-related syntax element.

[0097] By using the selected probability model, the entropy coding process can efficiently compress the partitioning information, leading to better overall compression performance. Entropy coding the syntax element related to the partitioning of the current block using the probability model can include decoding the syntax element from a compressed bitstream. Entropy coding the syntax element related to the partitioning of the current block using the probability model can include encoding the syntax element from a compressed bitstream.

[0098] For simplicity of explanation, the technique 1000 of FIG. 10 is depicted and described as a series of steps or operations. However, the steps or operations in accordance with this disclosure can occur in various orders and / or concurrently. Additionally, other steps or operations not presented and described herein may be used. Furthermore, not all illustrated steps or operations may be required to implement a technique in accordance with the disclosed subject matter.

[0099] Some implementations are described below as numbered examples (Example A, B, C, etc.). These examples are provided as examples only and do not limit the other implementations disclosed herein.

[0100] Example A is a method that includes determining a context for a current block, the current block having a block size and being partitioned into sub-blocks; mapping the block size to a context group using a block size map; selecting a probability model from a probability table based on the context and the context group; and entropy coding a syntax element related to partitioning of the current block using the probability model.

[0101] Example B is the method of Example A where the context is determined based on a left neighboring block and an above neighboring block of the current block.

[0102] Example C is the method of Example B where determining the context includes calculating a context value based on whether the left neighboring block has a same size as the current block and whether the above neighboring block has a same size as the current block; and combining the context value with a context group identifier using a predefined offset value.

[0103] Example D is the method of Example A where the block size map includes entries that map multiple block sizes of possible block sizes of the current block to a single context group.

[0104] Example E is the method of Example A where the context group is identified using an index into the block size map.

[0105] Example F is the method of Example A where the syntax element includes a flag that indicates whether the current block is partitioned according to one of a plurality of horizontal partition types and, when so partitioned, identifies which horizontal partition type is used.

[0106] Example G is the method of Example A where the syntax element includes a binary flag that indicates whether the current block is partitioned according to an uneven four-way partition.

[0107] Example H is the method of Example A where the syntax element includes a field that has two bits and identifies which of four predefined uneven four-way partitions is used to partition the current block.

[0108] Example I is the method of Example A where the syntax element indicates whether the current block is partitioned horizontally or vertically, and where entropy coding the syntax element is performed using a context model selected based on the block size independent of the block size map.

[0109] Example J is the method of Example A where entropy coding the syntax element related to the partitioning of the current block using the probability model includes decoding the syntax element from a compressed bitstream.

[0110] Example K is a device that includes a processor that is configured to perform the method of any one of Examples A to J.

[0111] Example L is a device that includes a memory and a processor, where the processor is configured to execute instructions stored in the memory to perform the method of any one of Examples A to J.

[0112] Example M is one or more non-transitory computer-readable storage media including executable instructions that, when executed by a processor, perform operations that perform the method of any one of Examples A to J.

[0113] Example N is one or more non-transitory computer-readable storage media having stored thereon a compressed bitstream, where the compressed bitstream is configured for decoding by the method of any one of Examples A to J.

[0114] Example O is one or more non-transitory computer-readable storage media having stored thereon a compressed bitstream, where the compressed bitstream is generated by an encoder performing the method of any one of Examples A to I.

[0115] The aspects of encoding and decoding described above illustrate some examples of encoding and decoding techniques. However, it is to be understood that encoding and decoding, as those terms are used in the claims, could mean compression, decompression, transformation, or any other processing or change of data.

[0116] The word “example” is used herein to mean serving as an example, instance, or illustration. Any aspect or design described herein as “example” is not necessarily to be construed as being preferred or advantageous over other aspects or designs. Rather, use of the word “example” is intended to present concepts in a concrete fashion. As used in this application, the term “or” is intended to mean an inclusive “or” rather than an exclusive “or.” That is, unless specified otherwise or clearly indicated otherwise by the context, the statement “X includes A or B” is intended to mean any of the natural inclusive permutations thereof. That is, if X includes A; X includes B; or X includes both A and B, then “X includes A or B” is satisfied under any of the foregoing instances. In addition, the articles “a” and “an” as used in this application and the appended claims should generally be construed to mean “one or more,” unless specified otherwise or clearly indicated by the context to be directed to a singular form. Moreover, use of the term “an implementation” or the term “one implementation” throughout this disclosure is not intended to mean the same embodiment or implementation unless described as such.

[0117] Implementations of the transmitting station 102 and / or the receiving station 106 (and the algorithms, methods, instructions, etc., stored thereon and / or executed thereby,including by the encoder 400 and the decoder 500) can be realized in hardware, software, or any combination thereof. The hardware can include, for example, computers, intellectual property (IP) cores, application- specific integrated circuits (ASICs), programmable logic arrays, optical processors, programmable logic controllers, microcode, microcontrollers, servers, microprocessors, digital signal processors, or any other suitable circuit. In the claims, the term “processor” should be understood as encompassing any of the foregoing hardware, either singly or in combination. The terms “signal” and “data” are used interchangeably. Further, portions of the transmitting station 102 and the receiving station 106 do not necessarily have to be implemented in the same manner.

[0118] Further, in one aspect, for example, the transmitting station 102 or the receiving station 106 can be implemented using a general purpose computer or general purpose processor with a computer program that, when executed, carries out any of the respective methods, algorithms, and / or instructions described herein. In addition, or alternatively, for example, a special purpose computer / processor can be utilized which can contain other hardware for carrying out any of the methods, algorithms, or instructions described herein.

[0119] The transmitting station 102 and the receiving station 106 can, for example, be implemented on computers in a video conferencing system. Alternatively, the transmitting station 102 can be implemented on a server, and the receiving station 106 can be implemented on a device separate from the server, such as a handheld communications device. In this instance, the transmitting station 102, using an encoder 400, can encode content into a compressed bitstream and transmit the compressed bitstream to the communications device. In turn, the communications device can then decode the compressed bitstream using a decoder 500. Alternatively, the communications device can decode content stored locally on the communications device, for example, content that was not transmitted by the transmitting station 102. Other suitable transmitting and receiving implementation schemes are available. For example, the receiving station 106 can be a generally stationary personal computer rather than a portable communications device, and / or a device comprising an encoder 400 may also comprise a decoder 500.

[0120] Further, all or a portion of implementations of the present disclosure can take the form of a computer program product accessible from, for example, a computer-usable or computer-readable medium. A computer-usable or computer-readable medium can be any device that can, for example, tangibly contain, store, communicate, or transport the program for use by or in connection with any processor. The medium can be, for example, anelectronic, magnetic, optical, electromagnetic, or semiconductor device. Other suitable mediums are also available.

[0121] The above-described embodiments, implementations, and aspects have been described in order to facilitate easy understanding of this disclosure and do not limit this disclosure. On the contrary, this disclosure is intended to cover various modifications and equivalent arrangements included within the scope of the appended claims, which scope is to be accorded the broadest interpretation as is permitted under the law so as to encompass all such modifications and equivalent arrangements.

Claims

What is claimed is:

1. A method, comprising: determining a context for a current block, the current block having a block size and being partitioned into sub-blocks; mapping the block size to a context group using a block size map; selecting a probability model from a probability table based on the context and the context group; and entropy coding a syntax element related to partitioning of the current block using the probability model.

2. The method of claim 1, wherein the context is determined based on a left neighboring block and an above neighboring block of the current block.

3. The method of claim 2, wherein determining the context comprises: calculating a context value based on whether the left neighboring block has a same size as the current block and whether the above neighboring block has a same size as the current block; and combining the context value with a context group identifier using a predefined offset value.

4. The method of claim 1, wherein the block size map comprises entries that map multiple block sizes of possible block sizes of the current block to a single context group.

5. The method of claim 1, wherein the context group is identified using an index into the block size map.

6. The method of any one of claim 1 to claim 5, wherein the syntax element comprises a flag that indicates whether the current block is partitioned according to one of a plurality of horizontal partition types and, when so partitioned, identifies which horizontal partition type is used.

7. The method of any one of claim 1 to claim 5, wherein the syntax element comprises a binary flag that indicates whether the current block is partitioned according to an uneven four-way partition.

8. The method of any one of claim 1 to claim 5, wherein the syntax element comprises a field that has two bits and identifies which of four predefined uneven four-way partitions is used to partition the current block.

9. The method of any one of claim 1 to claim 5, wherein the syntax element indicates whether the current block is partitioned horizontally or vertically, and wherein entropy coding the syntax element is performed using a context model selected based on the block size independent of the block size map.

10. The method of any one of claim 1 to claim 5, wherein entropy coding the syntax element related to the partitioning of the current block using the probability model comprises: decoding the syntax element from a compressed bitstream.

11. A device, comprising: a processor that is configured to perform the method of any one of claims 1 to 10.

12. A device, comprising: a memory; and a processor, the processor configured to execute instructions stored in the memory to perform the method of any one of claims 1 to 10.

13. A non-transitory computer-readable storage medium, comprising executable instructions that, when executed by a processor, perform operations that perform the method of any one of claims 1 to 10.

14. A non-transitory computer-readable storage medium having stored thereon a compressed bitstream, wherein the compressed bitstream is configured for decoding by the method of any one of claims 1 to 10.- l-15. A non-transitory computer-readable storage medium having stored thereon a compressed bitstream, wherein the compressed bitstream is generated by an encoder performing the method of any one of claims 1 to 9.

Images