WO2026024502A1 - Modèles de contexte partagés pour le signalement d'une partition de bloc - Google Patents

Modèles de contexte partagés pour le signalement d'une partition de bloc

Info

Publication number
WO2026024502A1
WO2026024502A1 PCT/US2025/037725 US2025037725W WO2026024502A1 WO 2026024502 A1 WO2026024502 A1 WO 2026024502A1 US 2025037725 W US2025037725 W US 2025037725W WO 2026024502 A1 WO2026024502 A1 WO 2026024502A1
Authority
WO
WIPO (PCT)
Prior art keywords
block
context
current block
syntax element
partition
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
PCT/US2025/037725
Other languages
English (en)
Inventor
In Suk Chong
Urvang Joshi
Debargha Mukherjee
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Google LLC
Original Assignee
Google LLC
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Google LLC filed Critical Google LLC
Publication of WO2026024502A1 publication Critical patent/WO2026024502A1/fr
Pending legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/10—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
    • H04N19/102—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the element, parameter or selection affected or controlled by the adaptive coding
    • H04N19/119—Adaptive subdivision aspects, e.g. subdivision of a picture into rectangular or non-rectangular coding blocks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/10—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
    • H04N19/169—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the coding unit, i.e. the structural portion or semantic portion of the video signal being the object or the subject of the adaptive coding
    • H04N19/17—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the coding unit, i.e. the structural portion or semantic portion of the video signal being the object or the subject of the adaptive coding the unit being an image region, e.g. an object
    • H04N19/176—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the coding unit, i.e. the structural portion or semantic portion of the video signal being the object or the subject of the adaptive coding the unit being an image region, e.g. an object the region being a block, e.g. a macroblock
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/70—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals characterised by syntax aspects related to video coding, e.g. related to compression standards
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/90—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using coding techniques not provided for in groups H04N19/10-H04N19/85, e.g. fractals
    • H04N19/91—Entropy coding, e.g. variable length coding [VLC] or arithmetic coding

Definitions

  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • One aspect of the disclosed implementations relates to the method, where the context group is identified using an index into the block size map.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • aspects can be implemented in any convenient form.
  • 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.
  • FIG. 1 is a schematic of a video encoding and decoding system.
  • FIG. 2 is a block diagram of an example of a computing device that can implement a transmitting station or a receiving station.
  • FIG. 3 is a diagram of a typical video stream to be encoded and subsequently decoded.
  • FIG. 4 is a block diagram of an encoder according to implementations of this disclosure.
  • FIG. 5 is a block diagram of a decoder according to implementations of this disclosure.
  • FIG. 6 is an illustration of examples of portions of a video frame.
  • FIG. 7 illustrates an example of block partitions.
  • FIG. 8 is a block diagram illustrating an example of selecting a probability model for coding a partitioning-related syntax element.
  • FIG. 9 illustrates an example of a block size map.
  • FIG. 10 is a flowchart of a technique for coding a partitioning of a current block.
  • 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.
  • a CU also referred to herein as a block, which may be the luminance component thereof
  • 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.
  • 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.
  • probability models i.e., probability distributions
  • a context 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.
  • partition-related syntax elements for each block size 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.
  • 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 decoder elects 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.
  • 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.
  • a network 104 can connect the transmitting station 102 and a receiving station 106 for encoding and decoding of the video stream.
  • 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.
  • 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.
  • an implementation can omit the network 104.
  • a video stream can be encoded and then stored for transmission at a later time to the receiving station 106 or any other device having memory.
  • 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.
  • a real-time transport protocol RTP
  • a transport protocol other than RTP may be used (e.g., a Hypertext Transfer Protocol-based (HTTP-based) video streaming protocol).
  • 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.
  • 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.
  • FIG. 2 is a block diagram of an example of a computing device 200 that can implement a transmitting station or a receiving station.
  • 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.
  • a processor 202 in the computing device 200 can be a conventional central processing unit.
  • the processor 202 can be another type of device, or multiple devices, capable of manipulating or processing information now existing or hereafter developed.
  • 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.
  • 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.
  • the application programs 210 can include applications 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.
  • 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.
  • 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.
  • 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.
  • LCD liquid crystal display
  • CRT cathode-ray tube
  • LED light emitting diode
  • OLED organic LED
  • 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.
  • 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.
  • 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.
  • 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 machines such as a network-based memory or memory in multiple machines performing the operations of the computing device 200.
  • the bus 212 of the computing device 200 can be composed of multiple buses.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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 size such 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.
  • 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.
  • the encoder 400 is a hardware encoder.
  • 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.
  • 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.
  • respective adjacent frames 304 can be processed in units of blocks.
  • respective blocks can be encoded using intra-frame prediction (also called intraprediction) or inter- frame prediction (also called inter-prediction).
  • intra-frame prediction also called intraprediction
  • inter-frame prediction also called inter-prediction
  • a prediction block can be formed.
  • intra-prediction a prediction block may be formed from samples in the current frame that have been previously encoded and reconstructed.
  • inter-prediction a prediction block may be formed from samples in one or more previously constructed reference frames.
  • 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 quantized transform coefficients, using a quantizer value or a quantization level. For example, the transform coefficients may be divided by the quantizer value and truncated.
  • 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.
  • VLC variable length 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.
  • 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).
  • 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.
  • a non-transform based encoder can quantize the residual signal directly without the transform stage 404 for certain blocks or frames.
  • an encoder can have the quantization stage 406 and the dequantization stage 410 combined in a common stage.
  • 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.
  • 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.
  • stages to perform various functions to produce an output video stream 516 from the compressed bitstream 420 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.
  • 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.
  • 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).
  • 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.
  • 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.
  • 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.
  • the video frame 600 may include CTUs larger than 64x64 and/or CUs smaller than 4x4.
  • the video frame 600 may be partitioned into various arrangements. Although one arrangement of CUs is shown, any arrangement may be used.
  • 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.
  • 32x64 CTUs, 64x32 CTUs, 16x32 CUs, 32x16 CUs, or any other size may be used.
  • Nx2N CTUs or CUs, 2NxN CTUs or CUs, or a combination thereof, may be used.
  • the pixels may include information representing an image captured in the video frame 600, such as luminance information, color information, and location information.
  • 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.
  • the luminance block 660 may include 16x16 luminance pixels 662 and each chrominance block 670, 680 may include 8x8 chrominance pixels 690 as shown.
  • 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.
  • 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.
  • 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.
  • quad-tree coding may include coding smaller CUs within a CTU in raster-scan order.
  • 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 bottom right 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • Reducing spatial redundancy may include transforming a CU into the frequency domain using, for example, a discrete cosine transform.
  • a unit of an encoder may perform a discrete cosine transform using transform coefficient values based on spatial frequency.
  • 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.
  • the video frame 600 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.
  • 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.
  • a color space other than the YUV color model may be used to represent the resolution of color channels of the video frame 600.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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-block 720B 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.
  • 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.
  • partitions may not be available for certain block sizes of the block 702.
  • the block 702 has the smallest possible sub-block size (e.g., 4x4), then it can not be further partitioned.
  • 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.
  • 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.
  • 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.
  • the rect_type syntax element may use ungrouped context models.
  • 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.
  • rect_type is encoded or decoded using the context model selected by its native block- size index, independent of the BSIZE_MAP grouping.
  • 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.
  • 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)
  • a value of 2 may indicate that the block 702 is partitioned according to the partition 714 (PARTITION_VERT_H).
  • 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.
  • 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) .
  • FIG. 8 is a block diagram illustrating an example 800 of selecting a probability model for coding a partitioning-related syntax element.
  • coding i.e., entropy coding
  • 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.
  • the example 800 includes a probability model selector 802, which can be implemented by or included in an entropy coding stage.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the block sizes 908 e.g., 4x16, 16x4, 8x32, 32x8, 16x64, and 64x16
  • 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).
  • subsets of these block sizes that meet the sizes criteria MxN and NxM can be mapped to the same group.
  • the block sizes 4x16 and 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.
  • 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 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.
  • the block size 806 represents the size of the current block being processed, such as the block 702 of FIG. 7.
  • the block size 806 is an indicator or an identifier of the size of the current block.
  • 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
  • the block size 806 can be used as an index into the block size map 804.
  • 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.
  • 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.
  • 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.
  • 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.
  • Table I illustrates an example of a pseudocode implemented by the probability model selector 802 for selecting the probability model 812.
  • 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.
  • 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.
  • 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.
  • 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.
  • coding 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.
  • 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.
  • 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.
  • 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. This ensures that the most appropriate probability model is used for entropy coding the partitioning-related syntax elements.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • Example E is the method of Example A where the context group is identified using an index into the block size map.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • Example K is a device that includes a processor that is configured to perform the method of any one of Examples A to J.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • Implementations of the transmitting station 102 and/or the receiving station 106 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.
  • IP intellectual property
  • ASICs application- specific integrated circuits
  • programmable logic arrays optical processors
  • programmable logic controllers programmable logic controllers
  • microcode microcontrollers
  • servers microprocessors, digital signal processors, or any other suitable circuit.
  • signal processors should be understood as encompassing any of the foregoing hardware, either singly or in combination.
  • signals 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.
  • 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.
  • 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.
  • the transmitting station 102 and the receiving station 106 can, for example, be implemented on computers in a video conferencing system.
  • 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.
  • the transmitting station 102 using an encoder 400, can encode content into a compressed bitstream and transmit the compressed bitstream to the communications device.
  • the communications device can then decode the compressed bitstream using a decoder 500.
  • the communications device can decode content stored locally on the communications device, for example, content that was not transmitted by the transmitting station 102.
  • 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.
  • 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, an electronic, magnetic, optical, electromagnetic, or semiconductor device. Other suitable mediums are also available.

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Compression Or Coding Systems Of Tv Signals (AREA)

Abstract

Selon l'invention, un contexte pour un bloc courant est déterminé. Le bloc courant a une taille de bloc et est divisé en sous-blocs. La taille de bloc est mappée à un groupe de contexte à l'aide d'une mappe de tailles de bloc. Un modèle de probabilité est sélectionné dans une table de probabilités sur la base du contexte et du groupe de contextes. Un élément de syntaxe lié au partitionnement du bloc courant est codé par entropie à l'aide du modèle de probabilité. Le contexte peut être déterminé sur la base d'un bloc voisin à gauche et d'un bloc voisin au-dessus du bloc courant. La détermination du contexte peut comprendre le calcul d'une valeur de contexte sur la base du fait que le bloc voisin à gauche a la même taille que le bloc courant et que le bloc voisin au-dessus a la même taille que le bloc courant, et la combinaison de la valeur de contexte avec un identifiant de groupe de contexte à l'aide d'une valeur de décalage prédéfinie.
PCT/US2025/037725 2024-07-22 2025-07-15 Modèles de contexte partagés pour le signalement d'une partition de bloc Pending WO2026024502A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US202463673955P 2024-07-22 2024-07-22
US63/673,955 2024-07-22

Publications (1)

Publication Number Publication Date
WO2026024502A1 true WO2026024502A1 (fr) 2026-01-29

Family

ID=96876672

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2025/037725 Pending WO2026024502A1 (fr) 2024-07-22 2025-07-15 Modèles de contexte partagés pour le signalement d'une partition de bloc

Country Status (1)

Country Link
WO (1) WO2026024502A1 (fr)

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP3306927A1 (fr) * 2016-10-05 2018-04-11 Thomson Licensing Procédé de codage et de décodage et dispositifs correspondants
US20210152823A1 (en) * 2017-07-07 2021-05-20 Samsung Electronics Co., Ltd. Video coding method and device, video decoding method and device
US20240205461A1 (en) * 2019-03-11 2024-06-20 Interdigital Vc Holdings, Inc. Entropy coding for video encoding and decoding

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP3306927A1 (fr) * 2016-10-05 2018-04-11 Thomson Licensing Procédé de codage et de décodage et dispositifs correspondants
US20210152823A1 (en) * 2017-07-07 2021-05-20 Samsung Electronics Co., Ltd. Video coding method and device, video decoding method and device
US20240205461A1 (en) * 2019-03-11 2024-06-20 Interdigital Vc Holdings, Inc. Entropy coding for video encoding and decoding

Similar Documents

Publication Publication Date Title
EP3590258B1 (fr) Sélection de noyau de transformée et codage entropique
GB2550995A (en) Block size adapative directional intra prediction
GB2546888B (en) Tile copying for video compression
EP2883357A2 (fr) Intra-prédiction de domaine de transformée
GB2582118A (en) Smart reordering in recursive block partitioning for advanced intra prediction in video coding
WO2019094080A1 (fr) Réduction d'artéfact de bloc
EP3725076B1 (fr) Sélection du chemin de balayage d'un bloc transformé dans le cadre du codage vidéo
KR102294438B1 (ko) 듀얼 디블로킹 필터 임계값들
WO2022005472A1 (fr) Prédiction inter-intra avec des modèles implicites
WO2026024502A1 (fr) Modèles de contexte partagés pour le signalement d'une partition de bloc
WO2024081010A1 (fr) Prédiction inter-composantes basée sur une région
WO2024081011A1 (fr) Simplification de dérivation de coefficients de filtre pour prédiction inter-composante
US20260012590A1 (en) Low-Complexity Filtering Of Fixed-Filtered Data
WO2024158769A1 (fr) Mode de saut hybride avec sous-bloc codé pour codage vidéo
WO2026050279A1 (fr) Codage de drapeau de commande au niveau de bloc dans un décalage d'échantillon inter-composantes
WO2024145086A1 (fr) Dérivation de contenu pour codage vidéo en mode de partitionnement géométrique
WO2024238680A1 (fr) Signalisation de mode de prédiction de chrominance
WO2026011182A1 (fr) Sélection de champ de mouvement de cadre de référence pour blocs en mode coin
WO2024242921A1 (fr) Indication de commande d'affichage déduite pour trames de présentation
WO2026055438A1 (fr) Mise à l'échelle dans le décalage d'échantillon entre composantes
WO2025059454A1 (fr) Filtrage de restauration multi-classe
WO2025255299A1 (fr) Stockage directionnel de vecteurs de mouvement de champ de mouvement de référence
WO2024005777A1 (fr) Transformation par décalage circulaire pour codage d'image et de vidéo
WO2024242888A1 (fr) Angles de prédiction intra étendus
WO2025230745A1 (fr) Codage entropique initialisé vers l'avant

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 25759503

Country of ref document: EP

Kind code of ref document: A1

DPE2 Request for preliminary examination filed before expiration of 19th month from priority date (pct application filed from 20040101)