CABAC Context Modeling Using Information from Spatial Neighbors

Abstract

A method of video decoding performed in a video decoder is provided, the method comprising: receiving coding information for a current block from a coded video bitstream; the coding information including a context coding syntax element associated with the current block, the syntax element indicating a decoding parameter for the current block; determining a context-based adaptive binary arithmetic coding (CABAC) context model associated with the context coding syntax element based on decoding parameters of more than two spatially neighboring blocks of the current block; decoding the context coding syntax element based on the determined CABAC context model associated with the context coding syntax element; and reconstructing the current block based on the decoded syntax element.

Description

[Technical field]

[0001] This disclosure describes embodiments that relate generally to video coding. [Background technology]

[0002] [Incorporated by reference] CROSS-REFERENCE TO RELATED APPLICATIONS This application claims the benefit of priority to U.S. Patent Application No. 18 / 125,631, entitled "CABAC CONTEXT MODELING WITH INFORMATION FROM SPATIAL NEIGHBORS," filed March 23, 2023, which claims the benefit of priority to U.S. Provisional Application No. 63 / 328,093, entitled "CABAC Context Modeling with Information from Spatial Neighbors," filed April 6, 2022. The disclosures of the prior applications are incorporated herein by reference in their entireties. [Background technology] The background discussion provided herein is intended to generally present the context of the present disclosure. The inventors' work, to the extent described in this background section, as well as aspects of the description that are not admitted as prior art at the time of filing, are not admitted, either explicitly or implicitly, as prior art to the present disclosure.

[0003] Image / video compression can help transmit image / video files across different devices, storage devices, and networks with minimal image quality degradation. In some examples, video codec technology can compress video based on spatial and temporal redundancy. In one example, video codecs can use a technique called intra prediction, which can compress images based on spatial redundancy. For example, intra prediction can use reference data from the current picture being reconstructed for sample prediction. In another example, video codecs can use a technique called inter prediction, which can compress images based on temporal redundancy. For example, inter prediction can predict samples in a current picture from previously reconstructed pictures using motion compensation. Motion compensation is commonly denoted by motion vectors (MVs). Summary of the Invention

[0004] Aspects of the present disclosure provide a method and apparatus for video encoding / decoding. In some examples, an apparatus for video decoding includes a receiving circuit and a processing circuit.

[0005] According to one aspect of the disclosure, a method of video decoding performed in a video decoder is provided. In the method, coding information of a current block may be received from a coded video bitstream. The coding information may include a context coded syntax element associated with the current block. The syntax element may indicate a decoding parameter of the current block. A context-based adaptive binary arithmetic coding (CABAC) context model associated with the context coded syntax element may be determined based on decoding parameters of more than two spatially neighboring blocks of the current block. The context coded syntax element may be decoded based on the determined CABAC context model associated with the context coded syntax element. The current block may be reconstructed based on the decoded syntax element.

[0006] In some embodiments, the more than two spatially neighboring blocks of the current block may include an upper right neighboring block, an above neighboring block, an upper left neighboring block, a left neighboring block, and a lower left neighboring block.

[0007] In some embodiments, the more than two spatially adjacent blocks of the current block may include a column of adjacent adjacent blocks to the left of the current block and a row of adjacent adjacent blocks above the current block.

[0008] In one example, the CABAC context model may be determined as one of four candidate context models assigned to the first bin associated with the syntax element.

[0009] In one example, the CABAC context model may be determined as one of four candidate context models based on (i) the number of spatially neighboring blocks of the current block being equal to or greater than a threshold, and (ii) the merge sub-block flag associated with each of the spatially neighboring blocks is false, or the inter-affine flag associated with each of the spatially neighboring blocks is false, or the local lighting compensation flag associated with each of the spatially neighboring blocks is false.

[0010] In some embodiments, the threshold may be equal to four.

[0011] In one example, the CABAC context model may be determined as the fourth context model of the four candidate context models based on: (i) the number of spatially neighboring blocks of the current block is equal to four; and (ii) the merge sub-block flag associated with each of the spatially neighboring blocks is false, or the inter-affine flag associated with each of the spatially neighboring blocks is false, or the local lighting compensation flag associated with each of the spatially neighboring blocks is false.

[0012] In response to (i) the number of spatially neighboring blocks of the current block being not greater than or equal to a threshold, or (ii) the merge sub-block flag associated with each of the spatially neighboring blocks being true, or the inter-affine flag associated with each of the spatially neighboring blocks being true, or the local lighting compensation flag associated with each of the spatially neighboring blocks being true, a CABAC context model may be selected from among the first, second, or third candidate context models of the four candidate context models based on one of the first decoding parameters of the left neighboring block or the second decoding parameters of the above neighboring block.

[0013] The CABAC context model may be selected based on (i) a first decoding parameter of the left neighboring block in response to the left neighboring block being available, or (ii) a second decoding parameter of the above neighboring block based on the above neighboring block being available.

[0014] In some embodiments, the syntax element may be one of an inter affine flag, a merge subblock flag, a local lighting compensation flag, a non-inter flag, a coding unit skip flag, a prediction mode flag, or an inter matrix-based intra prediction (mip) flag.

[0015] According to another aspect of the present disclosure, an apparatus is provided, the apparatus including a processing circuit, the processing circuit may be configured to perform any of the described methods for video decoding / encoding.

[0016] Aspects of the present disclosure also provide a non-transitory computer-readable medium storing instructions that, when executed by a computer, cause the computer to perform a method for video decoding / encoding. [Brief description of the drawings]

[0017] Further features, nature and various advantages of the disclosed subject matter will become more apparent from the following detailed description and the accompanying drawings. [Figure 1] FIG. 1 is a schematic diagram of an example block diagram of a communication system (100). [Diagram 2] FIG. 2 is a schematic diagram of an example block diagram of a decoder. [Diagram 3] FIG. 2 is a schematic diagram of an example block diagram of an encoder; [Figure 4] 1 is an example flowchart for decoding bins based on context-based adaptive binary arithmetic coding (CABAC) in accordance with some embodiments of the present disclosure. [Diagram 5] 2 shows exemplary locations of spatial neighbors of the current block. [Figure 6] 1 illustrates exemplary locations of spatial neighbors of a current block. [Figure 7] 1 shows a flowchart outlining a decoding process according to some embodiments of the present disclosure. [Figure 8] 1 shows a flowchart outlining an encoding process according to some embodiments of the present disclosure. [Figure 9] FIG. 1 is a schematic diagram of an exemplary computer system according to one embodiment. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0018] 1 illustrates a block diagram of a video processing system (100) in accordance with some examples. The video processing system (100) is an example of an application of the disclosed subject matter, as well as a video encoder and video decoder in a streaming environment. The disclosed subject matter is equally applicable to other video-enabled applications including, for example, video conferencing, digital TV, streaming services, storage of compressed video on digital media including CDs, DVDs, memory sticks, etc.

[0019] The video processing system (100) includes a capture subsystem (113) that may include a video source (101), such as, for example, a digital camera, that creates a stream of uncompressed video pictures (102). In one example, the stream of video pictures (102) includes samples taken by the digital camera. The stream of video pictures (102), shown as a thick line to emphasize the high data volume compared to the encoded video data (104) (or coded video bitstream), may be processed by an electronic device (120) that includes a video encoder (103) coupled to the video source (101). The video encoder (103) may include hardware, software, or a combination thereof to enable or implement aspects of the disclosed subject matter, as described in more detail below. The encoded video data (104) (or coded video bitstream), shown as a thin line to emphasize the lower data volume compared to the stream of video pictures (102), may be stored in a streaming server (105) for future use. One or more streaming client subsystems, such as the client subsystems (106) and (108) of FIG. 1, can access the streaming server (105) to retrieve copies (107) and (109) of the encoded video data (104). The client subsystem (106) can include a video decoder (110), for example, in an electronic device (130). The video decoder (110) decodes an incoming copy (107) of the encoded video data and creates an output stream (111) of video pictures that can be rendered on a display (112) (e.g., a display screen) or other rendering device (not shown). In some streaming systems, the encoded video data (104), (107), and (109) (e.g., a video bitstream) can be encoded according to some video coding / compression standard. Examples of these standards include ITU-T Recommendation H.265.In one example, the developing video coding standard is informally known as Versatile Video Coding (VVC). The disclosed subject matter may be used in the context of VVC.

[0020] It should be noted that the electronic devices (120) and (130) may include other components (not shown). For example, the electronic device (120) may include a video decoder (not shown), and the electronic device (130) may also include a video encoder (not shown).

[0021] 2 shows an example block diagram of a video decoder (210). The video decoder (210) may be included in an electronic device (230). The electronic device (230) may include a receiver (231) (e.g., a receiving circuit). The video decoder (210) may be used in place of the video decoder (110) in the example of FIG. 1.

[0022] The receiver (231) can receive one or more coded video sequences to be decoded by the video decoder (210). In one embodiment, one coded video sequence is received at a time, and the decoding of each coded video sequence is independent of the decoding of the other coded video sequences. The coded video sequences may be received from a channel (201), which may be a hardware / software link to a storage device that stores the coded video data. The receiver (231) can receive the coded video data along with other data, e.g., coded audio data and / or auxiliary data streams, which may be forwarded to respective usage entities (not shown). The receiver (231) can separate the coded video sequences from the other data. To address network jitter, a buffer memory (215) may be coupled between the receiver (231) and the entropy decoder / parser (220) (hereinafter "parser (220)"). In certain applications, the buffer memory (215) is part of the video decoder (210). In other embodiments, it may be external to the video decoder (210) (not shown). In yet other embodiments, there may be a buffer memory (not shown) external to the video decoder (210), for example to deal with network jitter, and there may be another buffer memory (215) internal to the video decoder (210), for example to handle playback timing. When the receiver (231) is receiving data from a storage / forwarding device with sufficient bandwidth and controllability, or from an isosynchronous network, the buffer memory (215) may not be needed or may be small. For use over a best-effort packet network such as the Internet, the buffer memory (215) may be needed and may be relatively large, advantageously adaptively sized, and may be implemented at least partially within an operating system or similar element (not shown) external to the video decoder (210).

[0023] The video decoder (210) may include a parser (220) for reconstructing symbols (221) from the coded video sequence. These categories of symbols include information used to manage the operation of the video decoder (210) and potentially information for controlling a rendering device such as a rendering device (212) (e.g., a display screen) that is not an integral part of the electronic device (230) but may be coupled to the electronic device (230) as shown in FIG. 2. The control information for the rendering device may be in the form of a Supplemental Enhancement Information (SEI) message or a Video Usability Information (VUI) parameter set fragment (not shown). The parser (220) may parse / entropy decode the received coded video sequence. The coding of the coded video sequence may follow a video coding technique or standard and may follow various principles including variable length coding, Huffman coding, arithmetic coding with or without context sensitivity, etc. The parser (220) can extract a set of subgroup parameters for at least one of the subgroups of pixels in the video decoder from the coded video sequence based on at least one parameter corresponding to the group. The subgroups can include groups of pictures (GOPs), pictures, tiles, slices, macroblocks, coding units (CUs), blocks, transform units (TUs), prediction units (PUs), etc. The parser (220) can also extract information from the coded video sequence, such as transform coefficients, quantization parameter values, motion vectors, etc.

[0024] The parser (220) can perform entropy decoding / parsing operations on the video sequence received from the buffer memory (215) to produce symbols (221).

[0025] The reconstruction of the symbols (221) may involve a number of different units, depending on the type of coded video picture or part thereof (inter-picture and intra-picture, inter-block and intra-block, etc.), as well as other factors. Which units are involved, and how, may be controlled by subgroup control information parsed from the coded video sequence by the parser (220). The flow of such subgroup control information between the parser (220) and the following units is not shown for clarity.

[0026] In addition to the functional blocks already mentioned, the video decoder (210) may be conceptually subdivided into a number of functional units, as described below. In an actual implementation operating under commercial constraints, many of these units may interact closely with each other and may be at least partially integrated with each other. However, for purposes of describing the disclosed subject matter, a conceptual subdivision into the following functional units is appropriate:

[0027] The first unit is a scalar / inverse transform unit (251), which receives quantized transform coefficients as well as control information from the parser (220) including which transform to use, block size, quantization coefficients, quantization scaling matrices, etc. as symbols (221). The scalar / inverse transform unit (251) can output a block containing sample values, which can be input to an aggregator (255).

[0028] In some cases, the output samples of the scaler / inverse transform unit (251) may relate to intra-coded blocks, which are blocks that do not use prediction information from a previously reconstructed picture, but can use prediction information from a previously reconstructed portion of the current picture. Such prediction information may be provided by the intra-picture prediction unit (252). In some cases, the intra-picture prediction unit (252) generates a block of the same size and shape as the block being reconstructed using surrounding already reconstructed information fetched from the current picture buffer (258). The current picture buffer (258) buffers, for example, a partially reconstructed current picture and / or a fully reconstructed current picture. The aggregator (255) adds, possibly on a sample-by-sample basis, the prediction information generated by the intra-prediction unit (252) to the output sample information provided by the scaler / inverse transform unit (251).

[0029] In other cases, the output samples of the scalar / inverse transform unit (251) may relate to an inter-coded, potentially motion-compensated block. In such cases, the motion compensated prediction unit (253) may access the reference picture memory (257) to fetch samples used for prediction. After motion compensating the fetched samples according to the symbols (221) associated with the block, these samples may be added by the aggregator (255) to the output of the scalar / inverse transform unit (251) (in this case referred to as residual samples or residual signals) to generate output sample information. The addresses in the reference picture memory (257) from which the motion compensated prediction unit (253) fetches prediction samples may be controlled by motion vectors available to the motion compensated prediction unit (253) in the form of symbols (221), which may have, for example, X, Y, and reference picture components. Motion compensation may also include interpolation of sample values ​​fetched from the reference picture memory (257) when sub-sample accurate motion vectors are used, motion vector prediction mechanisms, etc.

[0030] The output samples of the aggregator (255) may be subjected to various loop filtering techniques in the loop filter unit (256). Video compression techniques may include in-loop filter techniques that are controlled by parameters contained in the coded video sequence (also called a coded video bitstream) and made available to the loop filter unit (256) as symbols (221) from the parser (220). Video compression may be responsive to meta-information obtained during decoding of a previous portion (in decoding order) of the coded picture or coded video sequence, or may be responsive to previously reconstructed and loop filtered sample values.

[0031] The output of the loop filter unit (256) may be a sample stream that may be output to a rendering device (212) and stored in a reference picture memory (257) for use in future inter-picture prediction.

[0032] Once a coded picture is fully reconstructed, it may be used as a reference picture for future prediction. For example, once a coded picture corresponding to a current picture is fully reconstructed and the coded picture is identified as a reference picture (e.g., by the parser (220)), the current picture buffer (258) may become part of the reference picture memory (257), and a new current picture buffer may be reallocated before beginning reconstruction of a subsequent coded picture.

[0033] The video decoder 210 may perform decoding operations according to a given video compression technique or standard (e.g., ITU-T Rec. H.265). The coded video sequence may conform to a syntax specified by the video compression technique or standard being used in the sense that the coded video sequence conforms to both the syntax of the video compression technique or standard and to a profile documented in the video compression technique or standard. Specifically, a profile may select some tools from all tools available in the video compression technique or standard as the only tools available for use under that profile. Also, a requirement for conformance may be that the complexity of the coded video sequence is within the bounds as defined by the level of the video compression technique or standard. In some cases, the level limits the maximum picture size, maximum frame rate, maximum reconstruction sample rate (e.g., measured in megasamples per second), maximum reference picture size, etc. The limits set by the level may be further limited in some cases through a hypothetical reference decoder (HRD) specification and metadata for HRD buffer management signaled in the coded video sequence.

[0034] In one embodiment, the receiver (231) can receive additional (redundant) data along with the encoded video. The additional data may be included as part of the coded video sequence. The additional data may be used by the video decoder (210) to properly decode the data and / or to more accurately reconstruct the original video data. The additional data may be in the form of, for example, temporal, spatial, or signal-to-noise ratio (SNR) enhancement layers, redundant slices, redundant pictures, forward error correction codes, etc.

[0035] 3 shows an example block diagram of a video encoder (303). The video encoder (303) is included in an electronic device (320). The electronic device (320) includes a transmitter (340) (e.g., a transmission circuit). The video encoder (303) can be used in place of the video encoder (103) in the example of FIG. 1.

[0036] The video encoder (303) can receive video samples from a video source (301) (not part of the electronic device (320) in the example of FIG. 3) that can capture video images to be encoded by the video encoder (303). In another example, the video source (301) is part of the electronic device (320).

[0037] The video source (301) may provide a source video sequence to be coded by the video encoder (303) in the form of a digital video sample stream that may be of any suitable bit depth (e.g., 8-bit, 10-bit, 12-bit, ...), any color space (e.g., BT.601 Y CrCB, RGB, ...), and any suitable sampling structure (e.g., Y CrCB 4:2:0, Y CrCB 4:4:4). In a media delivery system, the video source (301) may be a storage device that stores previously prepared video. In a videoconferencing system, the video source (301) may be a camera that captures local image information as a video sequence. The video data may be provided as a number of individual pictures that give motion when viewed sequentially. The pictures themselves may be organized as a spatial array of pixels, each of which may comprise one or more samples depending on the sampling structure, color space, etc. in use. Those skilled in the art can easily understand the relationship between pixels and samples. The following description focuses on samples.

[0038] According to one embodiment, the video encoder (303) can code and compress pictures of a source video sequence into a coded video sequence (343) in real-time or under any other time constraint as needed. Enforcing an appropriate coding rate is one function of the controller (350). In some embodiments, the controller (350) controls and is operatively coupled to other functional units as described below, which coupling is not shown for clarity. Parameters set by the controller (350) can include rate control related parameters (picture skip, quantizer, lambda value for rate distortion optimization techniques, ...), picture size, group of pictures (GOP) layout, maximum motion vector search range, etc. The controller (350) can be configured to have other appropriate functions associated with the video encoder (303) optimized for a certain system design.

[0039] In some embodiments, the video encoder (303) is configured to operate in a coding loop. As an oversimplified explanation, in one example, the coding loop can include a source coder (330) (e.g., responsible for creating symbols, such as a symbol stream, based on an input picture to be coded and a reference picture(s)) and a (local) decoder (333) embedded in the video encoder (303). The decoder (333) reconstructs the symbols to create sample data in a similar manner as a (remote) decoder would. The reconstructed sample stream (sample data) is input to a reference picture memory (334). The decoding of the symbol stream results in a bit-exact result that is independent of the location of the decoder (local or remote), so the content in the reference picture memory (334) is also bit-exact between the local and remote encoders. In other words, the predictive part of the encoder "sees" exactly the same sample values ​​as the decoder would "see" when using prediction during decoding. This basic principle of reference picture synchrony (and the resulting drift if synchrony cannot be maintained, eg due to channel errors) is also used in several related techniques.

[0040] The operation of the "local" decoder (333) may be the same as that of a "remote" decoder, such as the video decoder (210) already described in detail above in connection with Figure 2. However, with brief reference also to Figure 2, because symbols are available and the encoding / decoding of the symbols into a coded video sequence by the entropy coder (345) and parser (220) may be lossless, the entropy decoding portion of the video decoder (210), including the buffer memory (215) and parser (220), may not be fully implemented in the local decoder (333).

[0041] In one embodiment, the decoder techniques, except for parsing / entropy decoding, present in the decoder are present in the corresponding encoder in the same or substantially the same functional form. Thus, the disclosed subject matter focuses on the decoder operation. The description of the encoder techniques may be omitted, since they are the inverse of the decoder techniques described generically. In certain areas, more detailed descriptions are provided below.

[0042] During operation, in some examples, the source coder (330) may perform motion-compensated predictive coding, which predictively codes an input picture with reference to one or more previously coded pictures from a video sequence designated as “reference pictures.” In this manner, the coding engine (332) codes differences between pixel blocks of the input picture and pixel blocks of reference pictures that may be selected as predictive references for the input picture.

[0043] The local video decoder (333) can decode coded video data of pictures that may be designated as reference pictures based on symbols created by the source coder (330). The operation of the coding engine (332) may advantageously be a lossy process. When the coded video data may be decoded in a video decoder (not shown in FIG. 3), the reconstructed video sequence may generally be a replica of the source video sequence with some errors. The local video decoder (333) can replicate the decoding process that may be performed on the reference pictures by the video decoder and store the reconstructed reference pictures in the reference picture memory (334). In this way, the video encoder (303) can locally store copies of reconstructed reference pictures that have common content with the reconstructed reference pictures obtained by the far-end video decoder (in the absence of transmission errors).

[0044] The predictor (335) can perform the prediction search of the coding engine (332). That is, for a new picture to be coded, the predictor (335) can search the reference picture memory (334) for sample data (as candidate reference pixel blocks) or specific metadata, such as reference picture motion vectors, block shapes, etc., that can serve as suitable prediction references for the new picture. The predictor (335) may operate on a sample block-by-pixel block basis to find suitable prediction references. In some cases, as determined by the search results obtained by the predictor (335), the input picture may have prediction references drawn from multiple reference pictures stored in the reference picture memory (334).

[0045] The controller (350) can manage the coding operations of the source coder (330), including, for example, setting the parameters and subgroup parameters used to encode the video data.

[0046] The output of all the aforementioned functional units is entropy coded in entropy coder 345. The entropy coder (345) converts the symbols produced by the various functional units into a coded video sequence by applying a lossless compression to the symbols according to techniques such as Huffman coding, variable length coding, or arithmetic coding.

[0047] The transmitter (340) may buffer the coded video sequence created by the entropy coder (345) for transmission over a communication channel (360), which may be a hardware / software link to a storage device that stores the coded video data. The transmitter (340) may merge the coded video data from the video encoder (303) with other data to be transmitted, such as coded audio data and / or auxiliary data streams (sources not shown).

[0048] The controller (350) may manage the operation of the video encoder (303). During coding, the controller (350) may assign to each coded picture a particular coded picture type, which may affect the coding technique that may be applied to the respective picture. For example, pictures may often be assigned as one of the following picture types:

[0049] An intra picture (I-picture) may be one that can be coded and decoded without using other pictures in a sequence as a source of prediction. Some video codecs allow different types of intra pictures, including, for example, Independent Decoder Refresh (IDR) pictures. Those skilled in the art are aware of these variations of I-pictures, as well as their respective uses and characteristics.

[0050] A predictive picture (P picture) may be one that can be encoded and decoded using intra- or inter-prediction, which uses at most one motion vector and reference index to predict sample values ​​for each block.

[0051] A bidirectionally predicted picture (B-picture) may be one that can be coded and decoded using intra- or inter-prediction that uses at most two motion vectors and reference indices to predict the sample values ​​of each block. Similarly, a multi-predicted picture may use more than two reference pictures and associated metadata for the reconstruction of a single block.

[0052] A source picture may generally be spatially subdivided into multiple sample blocks (e.g., blocks of 4x4, 8x8, 4x8, or 16x16 samples each) and coded block by block. Blocks may be predictively coded with reference to other (already coded) blocks as determined by the coding assignment applied to the respective picture of the block. For example, blocks of an I picture may be non-predictively coded or predictively coded with reference to already coded blocks of the same picture (spatial or intra prediction). Pixel blocks of a P picture may be predictively coded via spatial prediction or via temporal prediction with reference to one previously coded reference picture. Blocks of a B picture may be predictively coded via spatial prediction or via temporal prediction with reference to one or two previously coded reference pictures.

[0053] The video encoder (303) may perform coding operations according to a given video coding technique or standard, such as ITU-T Rec. H.265. In its operations, the video encoder (303) may perform various compression operations, including predictive coding operations that exploit temporal and spatial redundancy in the input video sequence. Thus, the coded video data may conform to a syntax specified by the video coding technique or standard being used.

[0054] In one embodiment, the transmitter (340) can transmit additional data along with the encoded video. The source coder (330) can include such data as part of the coded video sequence. The additional data can include temporal / spatial / SNR enhancement layers, other forms of redundant data such as redundant pictures and slices, SEI messages, VUI parameter set fragments, etc.

[0055] A video may be captured as multiple source pictures (video pictures) in a time sequence. Intra-picture prediction (often abbreviated as intra-prediction) exploits spatial correlation in a given picture, while inter-picture prediction exploits correlation (temporal or otherwise) between pictures. In one example, a particular picture being coded / decoded, called a current picture, is partitioned into blocks. When a block in the current picture resembles a reference block in a previously coded and still buffered reference picture in the video, the block in the current picture may be coded by a vector called a motion vector. A motion vector points to a reference block in the reference picture, and may have a third dimension that identifies the reference picture if multiple reference pictures are used.

[0056] In some embodiments, bi-prediction techniques may be used in inter-picture prediction. According to bi-prediction techniques, two reference pictures are used, such as a first reference picture and a second reference picture, both of which are earlier in decoding order than a current picture in a video (but may be in the past and future, respectively, in display order). A block in a current picture may be coded by a first motion vector that points to a first reference block in the first reference picture and a second motion vector that points to a second reference block in the second reference picture. A block may be predicted by a combination of the first reference block and the second reference block.

[0057] In addition, a merge mode technique can be used in inter-picture prediction to improve coding efficiency.

[0058] According to some embodiments of the present disclosure, predictions such as inter-picture prediction and intra-picture prediction are performed on a block-by-block basis. For example, according to the HEVC standard, pictures in a sequence of video pictures are partitioned into coding tree units (CTUs) for compression, and the CTUs in a picture have the same size, such as 64×64 pixels, 32×32 pixels, or 16×16 pixels. In general, a CTU includes three coding tree blocks (CTBs), one luma CTB and two chroma CTBs. Each CTU may be recursively quadtree split into one or more coding units (CUs). For example, a CTU of 64×64 pixels may be split into one CU of 64×64 pixels, or four CUs of 32×32 pixels, or 16 CUs of 16×16 pixels. In one example, each CU is analyzed to determine a prediction type of the CU, such as an inter prediction type or an intra prediction type. A CU is divided into one or more prediction units (PUs) according to temporal and / or spatial predictability. Generally, each PU includes a luma prediction block (PB) and two chroma PBs. In one embodiment, prediction operations during coding (encoding / decoding) are performed on a prediction block basis. Using a luma prediction block as an example of a prediction block, the prediction block includes a matrix of pixel values ​​(e.g., luma values) of 8×8 pixels, 16×16 pixels, 8×16 pixels, 16×8 pixels, etc.

[0059] It should be noted that the video encoders (103) and (303) and the video decoders (110) and (210) may be implemented using any suitable technique. In one embodiment, the video encoders (103) and (303) and the video decoders (110) and (210) may be implemented using one or more integrated circuits. In another embodiment, the video encoders (103) and (303) and the video decoders (110) and (210) may be implemented using one or more processors executing software instructions.

[0060] This disclosure includes embodiments related to entropy coding. For example, a context model for context-based adaptive binary arithmetic coding (CABAC) associated with a current block may be determined based on information from spatially neighboring blocks of the current block.

[0061] Local lighting compensation (LIC) may be an inter-prediction technique for modeling local lighting variations between a current block and its predicted block. The local lighting variations may be modeled as a function of the local lighting variations between a current block template and a reference block template. The parameters of the function may be denoted by a scale α and an offset β, which may form a linear equation α*p[x]+β to compensate for the lighting changes, where p[x] is a reference sample denoted by MV at location x on the reference picture. Since α and β are derived based on the current block template and the reference block template, no signaling overhead is required for the current block template and the reference block template. However, a LIC flag may be required to be signaled for the Advanced Motion Vector Prediction (AMVP) mode to indicate the use of LIC.

[0062] Local lighting compensation, previously proposed beyond VVC, can be used for uni-predictive Inter CUs with the following modifications: (1) Intra-neighbor samples may be used in LIC parameter derivation; (2) LIC is disabled for blocks with fewer than 32 luma samples; (2) For both non-subblock and affine modes, the LIC parameter derivation is may be performed based on the template block sample corresponding to the current CU instead of the partial template block sample corresponding to the first top-left 16×16 unit; (3) The samples of the reference block template are generated by using motion compensation (MC) based on the block MV, which does not need to be rounded to integer pel precision.

[0063] For example, for VVC, CABAC may include the following key changes compared to the design in HEVC: (1) Core CABAC engine; (2) separate residual coding structures for transform blocks and transform skip blocks; and (3) Context modeling of conversion coefficients.

[0064] The CABAC engine in HEVC uses a table-based probability transition process between 64 different representative probability states. In HEVC, the current interval range (e.g., ivlCurrRange), which represents the state of the coding engine, may be quantized to a set of four values ​​before the calculation of the new interval range. The HEVC state transition may be implemented using a table containing all 64×4 8-bit pre-calculated values ​​to approximate the value of ivlCurrRange*pLPS(pStateIdx), where pLPS is the probability of the least probable symbol (LPS) and pStateIdx is the index of the current state. Also, the decoding decision may be performed using a pre-calculated look-up table (LUT). For example, the LPS range (e.g., ivlLpsRange) may be determined based on the LUT, as in the following equation (1). The LPS range ivlLpsRange may be further used to update the current interval range ivlCurrRange and to calculate the output bin value (e.g., binVal).

[0065]

number

[0066] 4 shows an example flowchart (400) for decoding a single binary decision (e.g., decoding a bin) in VVC. As shown in the flowchart (400), at (S410), input variables of a context table (e.g., ctxTable) and a context index (e.g., ctxIdx) may be received. In some embodiments, the input variables may also include a current interval range (e.g., ivlCurrRange) and an interval offset (e.g., ivlOffset). At (S420), variables of a quantization range index (e.g., qRangeIdx), a probability state (e.g., pState), a most probable symbol value (e.g., valMps), and a most probable symbol interval range (e.g., ivlLpsRange) may be determined, and ivlCurrRange may be updated as ivlCurrRange_ivlLpsRange. In (S430), if ivlOffset is less than ivlCurrRange, the bin value (e.g., binVal) may be determined as valMps, as shown in (S450). When ivlOffset is greater than or equal to ivlCurrRange, the bin value (e.g., binVal) may be determined as 1-valMps, ivlOffset may be decremented by ivlCurrRange, and ivlCurrRange may be set equal to ivlLpsRange, as shown in (S440). In (S460), pStateIdx0 and pStateIdx0 may be updated based on the parameters of shift 0, shift 1, and bin value. In (S370), a renormalization process (e.g., RenormD) in the decoder may be performed based on the determined pStateIdx0 and pStateIdx0.

[0067] Similar to HEVC, VVC CABAC can also have a quantization parameter (QP) dependent initialization process that is invoked at the beginning of each slice. Given an initial value of luma QP for a slice, the initial probability state of the context model, denoted as preCtxState, can be derived in equations (2)-(4) as follows:

[0068]

number

[0069]

number

[0070]

number

[0071]

number

[0072]

number

[0073] In the derivation process of ctxTable, ctxIdx, and bypassFlag, the input to the derivation process may be the position of the current bin in the bin string. The position of the current bin in the bin string may be indicated as a bin index (e.g., binIdx). The output of the derivation process may be ctxTable, ctxIdx, and bypassFlag. The values ​​of ctxTable, ctxIdx, and bypassFlag may be derived based on the entry (or value) of binIdx of the corresponding syntax element in Table 1 as follows:

[0074] [Table 1] JPEG2025510445000009.jpg213146 If the entry in Table 1 is not equal to "bypass", "terminate", or "na", the value of binIdx may be decoded by invoking the DecodeDecision process. As shown in Table 1, the variable ctxInc may be specified by the corresponding entry in Table 1. When more than one value for binIdx is listed in Table 1, the assignment process of ctxInc for the corresponding binIdx may be further specified in the subclause given within the parentheses. The variable ctxIdxOffset may be set equal to the minimum of the current value of initType and the ctxIdx of the current syntax element. ctxIdx may be set equal to the sum of ctxInc and ctxIdxOffset. bypassFlag may be set equal to 0.

[0075] If the entry in Table 1 is equal to "bypass", the value of binIdx may be decoded by invoking the DecodeBypass process. Thus, ctxTable may be set equal to 0. ctxIdx may be set equal to 0. bypassFlag may be set equal to 1.

[0076] If the entry in Table 1 is equal to "terminate", the value of binIdx may be decoded by invoking the DecodeTerminate process. Thus, ctxTable may be set equal to 0. ctxIdx may be set equal to 0. bypassFlag may be set equal to 0.

[0077] If an entry in Table 1 is equal to "na", then the value of binIdx does not occur for the corresponding syntax element.

[0078] In the derivation process of ctxInc using the left and top syntax elements, the inputs to the derivation process may be the luma location (x0, y0) that specifies the top-left luma sample of the current luma block relative to the top-left sample of the current picture, the color components cIdx, the current coding quadtree depth cqtDepth, the dual tree channel type chType, the width and height of the current coding block in luma samples cbWidth and cbHeight, and variables derived in the coding tree semantics. The variables may include allowSplitBtVer, allowSplitBtHor, allowSplitTtVer, allowSplitTtHor, and allowSplitQt. The output of the derivation process may be the context index ctxInc.

[0079] In some embodiments, the position (xNbL, yNbL) may be set equal to (x0-1, y0), and a derivation process for neighboring block availability may be invoked based on the position (xCurr, yCurr) being set equal to (x0, y0), the neighboring position (xNbY, yNbY) being set equal to (xNbL, yNbL), checkPredModeY being set equal to FALSE, and cIdx being set as input. The output of the derivation process may be assigned to availableL.

[0080] In some embodiments, the position (xNbA, yNbA) may be set equal to (x0, y0-1), and a derivation process for neighboring block availability may be invoked based on the position (xCurr, yCurr) being set equal to (x0, y0), the neighboring position (xNbY, yNbY) being set equal to (xNbA, yNbA), checkPredModeY being set equal to FALSE, and cIdx being set as input. The output of the derivation process may be assigned to availableA.

[0081] In one example, the position (xCtb, yCtb) may be set equal to (x0>>CtbLog2SizeY, y0>>CtbLog2SizeY), the position (xCtbA, yCtbA) may be set equal to (xNbA>>CtbLog2SizeY, yNbA>>CtbLog2SizeY), and the position (xCtbL, yCtbL) may be set equal to (xNbL>>CtbLog2SizeY, yNbL>>CtbLog2SizeY).

[0082] The allocation of ctxInc may be specified as follows, using condL and condA as specified in Table 2. Table 2 shows the specification of ctxInc using left and top syntax elements. For syntax elements alf_ctb_flag[cIdx][xCtb][yCtb], alf_ctb_cc_cb_idc[xCtb][yCtb], alf_ctb_cc_cr_idc[xCtb][yCtb], split_qt_flag, split_cu_flag, cu_skip_flag[x0][y0], pred_mode_ibc_flag[x0][y0], intra_mip_flag, inter_affine_flag[x0][y0], and merge_subblock_flag[x0][y0] as shown in Table 2, ctxInc may be determined in equation (7) as follows:

[0083]

number

[0084]

number

[0085] [Table 2] In a related example, it may be inefficient to use information only from neighboring blocks above and to the left of the current block to derive a CABAC context model for inter_affine_flag or merge_subblock_flag, etc., for the current block.

[0086] In this disclosure, the context model for some syntax elements of a current block may depend on information of more than two spatially neighboring blocks of the current block. The syntax elements may include an inter-affine flag (e.g., inter_affine_flag) and / or a sub-block merge flag (e.g., merge_subblock_flag), and / or a lic_flag (e.g., a flag indicating whether an illumination compensation tool is used for a certain block / area), etc. In some embodiments, the syntax elements may be shown in Table 2.

[0087] For simplicity and clarity, embodiments of the present disclosure may be provided based on inter_affine_flag as an example syntax element.

[0088] In this disclosure, one or more additional context increments (e.g., ctxInc) may be used to determine the syntax element of the current block. ctxInc may indicate a context index (e.g., ctxIdx) of the context model. For example, ctxIdx may be set equal to the sum of ctxInc and ctxIdxOffset. ctxIdxOffset may be a fixed value that depends on the type of the syntax element and the type of slice (I, B, and P). The context increment (e.g., ctxInc) may be calculated using information such as the size of the current block, the type of the current block, and information of neighboring blocks of the current block. Thus, the context model of the syntax element may be derived according to information of M spatially neighboring blocks of the current block, where M may be a positive integer.

[0089] In one embodiment, M may be equal to 5. The five spatial neighbors of the current block may be as shown in Figure 5. As shown in Figure 5, the current block 502 may include a top right (B0) neighboring block, a top (B1) neighboring block, a top left (B2) neighboring block, a left (A1) neighboring block, and a bottom left (A0) neighboring block. Each of the neighboring blocks may have different sizes. For example, each neighboring block in Figure 5 may include 4x4 luma samples.

[0090] In one embodiment, M may be equal to the number of all sub-blocks from the bottom left (LB) position to the top left (AL) position and from the top left (AL) position to the top right (AR) position, which may be shown in Figure 6. As shown in Figure 6, the current block 602 may include a column of adjacent neighboring blocks (e.g., LB, L0, L1, L2, L3, AL) to the left of the current block 602 and a row of adjacent neighboring blocks (AL, A3, A2, A1, A0, AR) to the top of the current block 602. Each of the neighboring blocks may have different sizes. For example, each neighboring block in Figure 6 may include 4x4 luma samples.

[0091] In one embodiment, the additional ctxInc for inter_affine_flag may be as shown in Table 3. As shown in Table 3, four values ​​of ctxInc (e.g., 0, 1, 2, and 3) may be provided for the first context-coded bin (e.g., binIdx=0) of inter_affine_flag.

[0092] [Table 3] In another embodiment, the additional ctxInc for merge_subblock_flag may be as shown in Table 4. As shown in Table 4, four values ​​of ctxInc (e.g., 0, 1, 2, and 3) may be provided for the first context-coded bin (e.g., binIdx=0) of merge_subblock_flag.

[0093] [Table 4] In one embodiment, the ctxInc of inter_affine_flag may be set as 3 based on a combination of the following two conditions: (1) N or more of the five spatial neighbors (e.g., A0, A1, B0, B1, and B2 in FIG. 5) are available. In one example, N is equal to 4. (2) For each of the available spatial neighbors, the merge subblock flag is false (e.g., MergeSubblockFlag) or the interAffine flag is false: (outside 1) JPEG2025510445000017.jpg19150 Otherwise, if at least one of the two conditions is not satisfied, the value of ctxInc of inter_affine_flag may be derived according to the left and top neighbor conditions condL and condA, respectively. condL and condA may be determined based on Table 2. ctxInc may be determined as 0, 1, or 2 based on Equation (9), as follows:

[0094]

number

[0095] In one embodiment, the ctxInc of merge_subblock_flag may be set as 3 based on a combination of the following two conditions: (1) N or more of the five (e.g., A0, A1, B0, B1, and B2 in FIG. 5) spatial neighbors are available. In one example, N is equal to 4. (2) For each of the available spatial neighbors, the merge subblock flag (e.g., MergeSubblockFlag) is false or the inter-affine flag (e.g., InterAffineFlag) is false: (outside 4) Otherwise, if at least one of the two conditions is not satisfied, the value of ctxInc of merge_subblock_flag may be derived according to the left and top neighbor conditions condL and condA, respectively. condL and condA may be determined based on Table 2. ctxInc may be determined as 0, 1, or 2 based on Equation (10) as follows:

[0096]

number

[0097] Four values ​​of ctxInc may be provided for the first context coded bin (eg, binIdx=0) of lic_flag, as shown in Table 5. Table 6 shows the conditions for the left neighboring block and the upper neighboring block of the current block.

[0098] [Table 5]

[0099] [Table 6] In one example, ctxInc of lic_flag may be set as 3 based on a combination of the following two conditions: (1) N or more of the five (e.g., A0, A1, B0, B1, and B2 in FIG. 5) spatial neighbors are available. In one example, N is equal to 4. (2) The LIC flag for each of the available spatial neighbors is false. Otherwise, if at least one of the two conditions is not met, ctxInc of lic_flag may be derived according to the conditions condL and condA of the left and top neighbors, respectively. condL and condA may be determined based on Table 6. ctxInc may be determined as 0, 1, or 2 based on Equation (11), as follows:

[0100]

number

[0101] 7 shows a flow chart outlining a process (700) according to one embodiment of the disclosure. The process (700) may be used in a video decoder. In various embodiments, the process (700) is performed by a processing circuit, such as a processing circuit performing the functions of the video decoder (110), a processing circuit performing the functions of the video decoder (210), etc. In some embodiments, the process (700) is implemented with software instructions, such that the processing circuit performs the process (700) when it executes the software instructions. The process proceeds from (S701) to (S710).

[0102] At (S710), coding information for a current block is received from a coded video bitstream, the coding information including a context coding syntax element associated with the current block, the syntax element indicating a decoding parameter for the current block.

[0103] At (S720), a context-based adaptive binary arithmetic coding (CABAC) context model associated with the context coding syntax element is determined based on decoding parameters of more than two spatially neighboring blocks of the current block.

[0104] At (S730), the context coded syntax element is decoded based on the determined CABAC context model associated with the context coded syntax element.

[0105] At (S740), the current block can be reconstructed based on the decoded syntax elements.

[0106] In some embodiments, the more than two spatially neighboring blocks of the current block include an upper right neighboring block, an above neighboring block, an upper left neighboring block, a left neighboring block, and a lower left neighboring block.

[0107] In some embodiments, the more than two spatially neighboring blocks of the current block include a column of neighboring blocks to the left of the current block and a row of neighboring blocks above the current block.

[0108] In one example, the CABAC context model is determined as one of four candidate context models assigned to the first bin associated with the syntax element.

[0109] In one example, the CABAC context model is determined as one of four candidate context models based on (i) the number of spatially neighboring blocks of the current block being equal to or greater than a threshold, and (ii) the merge sub-block flag associated with each of the spatially neighboring blocks is false, or the inter-affine flag associated with each of the spatially neighboring blocks is false, or the local lighting compensation flag associated with each of the spatially neighboring blocks is false.

[0110] In some embodiments, the threshold value is equal to four.

[0111] In one example, the CABAC context model is determined as the fourth context model of the four candidate context models based on (i) the number of spatially neighboring blocks of the current block is equal to four, and (ii) the merge sub-block flag associated with each of the spatially neighboring blocks is false, or the inter-affine flag associated with each of the spatially neighboring blocks is false, or the local lighting compensation flag associated with each of the spatially neighboring blocks is false.

[0112] In response to (i) the number of spatially neighboring blocks of the current block being not greater than or equal to a threshold, or (ii) the merge sub-block flag associated with each of the spatially neighboring blocks being true, or the inter-affine flag associated with each of the spatially neighboring blocks being true, or the local illumination compensation flag associated with each of the spatially neighboring blocks being true, a CABAC context model is selected from among the first, second, or third candidate context models of the four candidate context models based on one of the first decoding parameters of the left neighboring block or the second decoding parameters of the above neighboring block.

[0113] In one example, the CABAC context model is selected based on (i) a first decoding parameter of a left neighboring block depending on the availability of the left neighboring block, or (ii) a second decoding parameter of an upper neighboring block based on the upper neighboring block being available.

[0114] In some embodiments, the syntax element is one of an inter affine flag, a merge subblock flag, a local lighting compensation flag, a non-inter flag, a coding unit skip flag, a prediction mode flag, or an inter matrix-based intra prediction (mip) flag.

[0115] Next, the process proceeds to (S799) and ends.

[0116] Process (700) may be adapted as appropriate. Steps of process (700) may be modified and / or omitted. Additional steps may be added. Any suitable order of performance may be used.

[0117] 8 shows a flow chart outlining a process (800) according to one embodiment of the present disclosure. The process (800) may be used in a video encoder. In various embodiments, the process (800) is performed by a processing circuit, such as a processing circuit performing the functions of a video encoder (103), a processing circuit performing the functions of a video encoder (303), etc. In some embodiments, the process (800) is implemented with software instructions, such that the processing circuit performs the process (800) when it executes the software instructions. The process proceeds from (S801) to (S810).

[0118] At (S810), a context-based adaptive binary arithmetic coding (CABAC) context model is determined from a plurality of candidate context models for encoding a syntax element associated with a current block based on encoding parameters of more than two spatially neighboring blocks of the current block.

[0119] At (S820), a syntax element associated with the current block is context coded based on the determined CABAC context model, the syntax element indicating coding parameters of the current block.

[0120] At (S830), coding information of the current block is generated based on the determined CABAC context model, where the coding information includes a context coding syntax element associated with the current block.

[0121] The process then proceeds to (S899) and ends.

[0122] Process (800) may be adapted as appropriate. Steps of process (800) may be modified and / or omitted. Additional steps may be added. Any suitable order of performance may be used.

[0123] The techniques described above may be implemented as computer software using computer readable instructions and physically stored on one or more computer readable media. For example, Figure 9 illustrates a computer system (900) suitable for implementing certain embodiments of the disclosed subject matter.

[0124] Computer software can be coded using any suitable machine code or computer language, which can be assembled, compiled, linked, or similar mechanisms to produce code including instructions that can be executed by one or more computer central processing units (CPUs), graphics processing units (GPUs), etc., directly, or via interpretation, via microcode execution, etc.

[0125] The instructions may be executed on various types of computers or components thereof, including, for example, personal computers, tablet computers, servers, smart phones, gaming devices, Internet of Things devices, and the like.

[0126] 9 for computer system (900) are exemplary in nature and are not intended to suggest any limitation as to the scope of use or functionality of the computer software implementing the embodiments of the present disclosure, nor should the arrangement of components be interpreted as having any dependency or requirement regarding any one or combination of components illustrated in the exemplary embodiment of computer system (900).

[0127] The computer system (900) may include human interface input devices. Such human interface input devices may respond to input by one or more human users through, for example, tactile input (keystrokes, swipes, data glove movements, etc.), audio input (voice, clapping), visual input (gestures, etc.), olfactory input (not shown), etc. Human interface devices may also be used to capture certain media not necessarily directly associated with conscious human input, such as audio (speech, music, ambient sounds, etc.), images (scanned images, photographic images obtained from a still image camera, etc.), and video (two-dimensional video, three-dimensional video including stereoscopic video, etc.).

[0128] The input human interface devices may include one or more (only one of each is shown) of a keyboard (901), a mouse (902), a trackpad (903), a touch screen (910), a data glove (not shown), a joystick (905), a microphone (906), a scanner (907), and a camera (908).

[0129] The computer system (900) may also include human interface output devices. Such human interface output devices may stimulate one or more of the senses of a human user, for example, through haptic output, sound, light, and smell / taste. Such human interface output devices may include haptic output devices (e.g., haptic feedback via a touch screen (910), data gloves (not shown), or joystick (905), although there may also be haptic feedback devices that do not function as input devices), audio output devices (speakers (909), headphones (not shown), etc.), visual output devices (such as screens (910), including CRT screens, LCD screens, plasma screens, OLED screens, etc., with or without touch screen input capability, with or without haptic feedback capability, some of which may be capable of outputting two-dimensional visual output or more than three-dimensional output through means such as stereoscopic output), virtual reality glasses (not shown), holographic displays, and smoke tanks (not shown), as well as printers (not shown).

[0130] The computer system (900) may also include human accessible storage devices and their associated media, such as optical media, including CD / DVD ROM / RW (920) with media (921) such as CDs / DVDs, thumb drives (922), removable hard drives or solid state drives (923), legacy magnetic media such as tape and floppy disks (not shown), and dedicated ROM / ASIC / PLD based devices such as security dongles (not shown).

[0131] Those skilled in the art will also understand that the term "computer-readable medium" as used in connection with the subject matter disclosed herein does not encompass transmission media, carrier waves, or other transitory signals.

[0132] The computer system (900) may also include an interface (954) to one or more communication networks (955). The networks may be, for example, wireless, wired, optical. The networks may further be local, wide area, metropolitan, vehicular and industrial, real-time, delay tolerant, etc. Examples of networks include local area networks such as Ethernet, WLAN, cellular networks including GSM, 3G, 4G, 5G, LTE, etc., television wired or wireless wide area digital networks including cable television, satellite television, and terrestrial broadcast television, vehicular and industrial including CANBus. Some networks typically require an external network interface adapter attached to some general purpose data port or peripheral bus (949) (e.g., a USB port of the computer system (900)), while other networks are typically integrated into the core of the computer system (900) by attachment to a system bus (e.g., an Ethernet interface to a PC computer system or a cellular network interface to a smartphone computer system), as described below. Using any of these networks, the computer system (900) can communicate with other entities. Such communications can be one-way receive-only (e.g., broadcast TV), one-way transmit-only (e.g., from the CANbus to a particular CANbus device), or bidirectional, for example, to other computer systems using local or wide area digital networks. Certain protocols and protocol stacks can be used over each of these networks and network interfaces, as described above.

[0133] The aforementioned human interface devices, human accessible storage devices, and network interfaces may be attached to a core (940) of the computer system (900).

[0134] The cores (940) may include one or more central processing units (CPUs) (941), graphics processing units (GPUs) (942), dedicated programmable processing units in the form of field programmable gate areas (FPGAs) (943), hardware accelerators for specific tasks (944), graphics adapters (950), etc. These devices may be connected via a system bus (948) along with read only memory (ROM) (945), random access memory (946), internal mass storage devices (947) such as internal non-user accessible hard drives, SSDs, etc. In some computer systems, the system bus (948) may be accessible in the form of one or more physical plugs to allow expansion with additional CPUs, GPUs, etc. Peripheral devices may be connected directly to the core's system bus (948) or via a peripheral bus (949). In one example, a screen (910) may be connected to the graphics adapter (950). Peripheral bus architectures include PCI, USB, etc.

[0135] The CPU (941), GPU (942), FPGA (943), and accelerator (944) can execute certain instructions, which in combination can constitute the aforementioned computer code. The computer code can be stored in ROM (945) or RAM (946). Also, transient data can be stored in RAM (946), while persistent data can be stored, for example, in an internal mass storage device (947). Rapid storage and retrieval from any of the memory devices can be made possible through the use of cache memory, which can be closely associated with one or more of the CPU (941), GPU (942), mass storage device (947), ROM (945), RAM (946), etc.

[0136] The computer-readable medium can bear computer code for performing various computer-implemented operations. The medium and computer code may be those specially designed and constructed for the purposes of the present disclosure, or they may be of the kind well known and available to those skilled in the computer software arts.

[0137] By way of example and not limitation, a computer system having the architecture (900), and in particular the core (940), can provide functionality as a result of a processor (including a CPU, GPU, FPGA, accelerator, etc.) executing software embodied in one or more tangible computer-readable media. Such computer-readable media can be user-accessible mass storage devices as introduced above, as well as media associated with a particular storage device of the core (940) that is non-transitory in nature, such as the core internal mass storage device (947) or ROM (945). Software implementing various embodiments of the present disclosure can be stored in such devices and executed by the core (940). The computer-readable media can include one or more memory devices or chips, depending on the particular needs. The software can cause the core (940), and in particular the processor therein (including a CPU, GPU, FPGA, etc.) to perform certain processes or certain portions of certain processes described herein, including defining data structures stored in RAM (946) and modifying such data structures in accordance with the processes defined by the software. Additionally, or alternatively, a computer system may provide functionality as a result of logic hardwired or otherwise embodied in circuitry (e.g., accelerator (944)) that may operate in place of or in conjunction with software to perform certain processes or certain portions of certain processes described herein. References to software may encompass logic, and vice versa, where appropriate. References to computer-readable media may encompass, where appropriate, circuitry (such as an integrated circuit (IC)) that stores software for execution, circuitry that embodies logic for execution, or both. The present disclosure encompasses any appropriate combination of hardware and software.

[0138] While this disclosure has described several exemplary embodiments, there are alterations, permutations, and various substitute equivalents that fall within the scope of this disclosure. Of course, those skilled in the art will be able to devise numerous systems and methods not explicitly shown or described herein, but which embody the principles of this disclosure and thus are within the spirit and scope of the disclosure.

Claims

1. 1. A method of video decoding performed in a video decoder, comprising: receiving coding information for a current block from a coded video bitstream, the coding information including a context coding syntax element associated with the current block, the syntax element indicating a decoding parameter for the current block; determining a context-based adaptive binary arithmetic coding (CABAC) context model associated with the context coding syntax element based on decoding parameters of more than two spatially neighboring blocks of the current block; decoding the context coding syntax element based on the determined CABAC context model associated with the context coding syntax element; reconstructing the current block based on the decoded syntax elements; and A method comprising:

2. The method of claim 1 , wherein the more than two spatial neighboring blocks of the current block include an upper right neighboring block, an above neighboring block, an upper left neighboring block, a left neighboring block, and a lower left neighboring block.

3. 2. The method of claim 1, wherein the more than two spatially neighboring blocks of the current block include a column of neighboring blocks to the left of the current block and a row of neighboring blocks above the current block.

4. Determining the CABAC context model further comprises:

3. The method of claim 2, comprising determining the CABAC context model as one of four candidate context models assigned to a first bin associated with the syntax element.

5. Determining the CABAC context model further comprises: determining the CABAC context model as the one of the four candidate context models based on: (i) a number of the spatial neighboring blocks of the current block being equal to or greater than a threshold; and (ii) a merge sub-block flag associated with each of the spatial neighboring blocks being false, or an inter-affine flag associated with each of the spatial neighboring blocks being false, or a local illumination compensation flag associated with each of the spatial neighboring blocks being false. The method according to claim 4.

6. 6. The method of claim 5, wherein the CABAC context model is determined as a fourth context model of the four candidate context models based on: (i) a number of the spatially neighboring blocks of the current block is equal to four; and (ii) the Merge sub-block flag associated with each of the spatially neighboring blocks is false, or the Inter-Affine flag associated with each of the spatially neighboring blocks is false, or the local lighting compensation flag associated with each of the spatially neighboring blocks is false.

7. Determining the CABAC context model as one of the four candidate context models further comprises: (i) in response to a number of the spatial neighboring blocks of the current block being not greater than or equal to the threshold, or (ii) the merge sub-block flag associated with each of the spatial neighboring blocks being true, or the inter-affine flag associated with each of the spatial neighboring blocks being true, or the local illumination compensation flag associated with each of the spatial neighboring blocks being true. selecting the CABAC context model from among a first, a second, or a third candidate context model of the four candidate context models based on one of a first decoding parameter of the left neighboring block or a second decoding parameter of the above neighboring block. The method according to claim 6.

8. The selecting step further comprises: selecting the CABAC context model based on (i) the first decoding parameter of the left neighboring block in response to the left neighboring block being available, or (ii) the second decoding parameter of the above neighboring block in response to the above neighboring block being available. The method according to claim 7.

9. 2. The method of claim 1, wherein the syntax element is one of an inter affine flag, a merge subblock flag, a local lighting compensation flag, a non-inter flag, a coded unit skip flag, a prediction mode flag, or an inter matrix-based intra prediction (mip) flag.

10. An apparatus having a processing circuit, The processing circuitry includes: receiving coding information for a current block from a coded video bitstream, the coding information including a context coding syntax element associated with the current block, the syntax element indicating a decoding parameter for the current block; determining a context-based adaptive binary arithmetic coding (CABAC) context model associated with the context coding syntax element based on decoding parameters of more than two spatially neighboring blocks of the current block; decoding the context coding syntax element based on the determined CABAC context model associated with the context coding syntax element; An apparatus configured to reconstruct the current block based on the decoded syntax elements.

11. The apparatus of claim 10 , wherein the more than two spatial neighboring blocks of the current block include a top right neighboring block, an above neighboring block, a top left neighboring block, a left neighboring block, and a bottom left neighboring block.

12. 11. The apparatus of claim 10, wherein the more than two spatially neighboring blocks of the current block include a column of neighboring blocks to the left of the current block and a row of neighboring blocks above the current block.

13. The processing circuitry further comprises:

12. The apparatus of claim 11, configured to determine the CABAC context model as one of four candidate context models assigned to a first bin associated with the syntax element.

14. The processing circuitry further comprises: configured to determine the CABAC context model as the one of the four candidate context models based on: (i) a number of the spatial neighboring blocks of the current block is equal to or greater than a threshold; and (ii) a merge sub-block flag associated with each of the spatial neighboring blocks is false, or an inter-affine flag associated with each of the spatial neighboring blocks is false, or a local illumination compensation flag associated with each of the spatial neighboring blocks is false.

14. The apparatus of claim 13.

15. the CABAC context model is determined as a fourth context model of the four candidate context models based on: (i) a number of the spatially neighboring blocks of the current block is equal to four; and (ii) the merge sub-block flag associated with each of the spatially neighboring blocks is false, or the inter-affine flag associated with each of the spatially neighboring blocks is false, or the local illumination compensation flag associated with each of the spatially neighboring blocks is false.

15. The apparatus of claim 14.

16. The processing circuitry further comprises: (i) in response to a number of the spatial neighboring blocks of the current block being not greater than or equal to the threshold, or (ii) the merge sub-block flag associated with each of the spatial neighboring blocks being true, or the inter-affine flag associated with each of the spatial neighboring blocks being true, or the local illumination compensation flag associated with each of the spatial neighboring blocks being true. and configured to select the CABAC context model from among a first, a second, or a third candidate context model of the four candidate context models based on one of a first decoding parameter of the left neighboring block or a second decoding parameter of the top neighboring block.

16. The apparatus of claim 15.

17. The processing circuitry further comprises: and (ii) selecting the CABAC context model based on the first decoding parameters of the left neighboring block in response to the left neighboring block being available, or based on the second decoding parameters of the above neighboring block being available.

17. The apparatus of claim 16.

18. 11. The apparatus of claim 10, wherein the syntax element is one of an inter affine flag, a merge subblock flag, a local lighting compensation flag, a non-inter flag, a coded unit skip flag, a prediction mode flag, or an inter matrix-based intra prediction (mip) flag.

19. A non-transitory computer readable medium storing instructions, the instructions comprising: When executed by at least one processor, the method causes the at least one processor to perform the steps of the method according to any one of claims 1 to 10. A non-transitory computer-readable storage medium.

Images