Method, apparatus, and computer program for reducing context model for entropy coding of transform coefficient significance flag

JP2025036426A5Active Publication Date: 2025-10-31TENCENT AMERICA LLC
View PDF 0 Cites 0 Cited by

Patent Information

Application Number
JP2024206395
Authority / Receiving Office
JP · JP
Patent Type
Applications
Current Assignee / Owner
Priority Date
2020-06-17
Filing Date
2024-11-27
Publication Date
2025-10-31
Estimated Expiration
2040-06-18

AI Technical Summary

Benefits of technology

【0019】 開示された主題のさらなる特徴、性質、および様々な利点は、以下の詳細な説明および添付の図面からより明らかになるであろう。

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure 00000000_0000_ABST
    Figure 00000000_0000_ABST
Patent Text Reader

Abstract

To provide a method and an apparatus that reduce a context model for entropy coding of a conversion coefficient significance flag.SOLUTION: A method of video decoding performed in a video decoder includes the steps of receiving an encoded video bitstream including a current picture and at least one syntax element corresponding to transform coefficients of a transform block within the current picture, determining an offset value on the basis of the output of a monotonically non-decreasing f(x) function performed on the sum (x) of a group of partially reconstructed transform coefficients, determining a context model index on the basis of the sum of the determined offset value and a base value, and selecting a context model from the plurality of context models on the basis of the determined context model index for at least one syntax of the current transformation coefficient.SELECTED DRAWING: Figure 16
Need to check novelty before this filing date? Find Prior Art

Description

[Technical field]

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS This disclosure claims the benefit of priority to U.S. Provisional Application No. 62 / 863,742, entitled "METHOD OF REDUCING CONTEXT MODELS FOR ENTROPY CODING OF TRANSFORM COEFFICIENT SIGNIFICANT FLAG," filed June 17, 2020, which claims the benefit of priority to U.S. Provisional Application No. 62 / 863,742, entitled "METHOD OF REDUCING CONTEXT MODELS FOR ENTROPY CODING OF TRANSFORM COEFFICIENT SIGNIFICANT FLAG," filed June 19, 2019, the entire contents of which are incorporated herein by reference.

[0002] This disclosure describes embodiments generally relating to video coding. [Background technology]

[0003] The background art description provided herein is intended to generally present the context of the present disclosure. The inventors' work is not admitted expressly or impliedly as prior art to the present disclosure, to the extent that it is described in this background art section, and aspects of the description that may not be admitted as prior art at the time of filing.

[0004] Video encoding and decoding can be done using inter-picture prediction with motion compensation. Uncompressed digital video can include a sequence of pictures, each with spatial dimensions of, for example, 1920x1080 luma samples and associated chroma samples. The sequence of pictures can have a fixed or variable picture rate (also informally known as frame rate), for example, 60 pictures per second or 60 Hz. Uncompressed video has significant bitrate requirements. For example, 1080p60 4:2:0 video (1920x1080 luma sample resolution at a frame rate of 60 Hz) with 8 bits per sample requires a bandwidth approaching 1.5 Gbit / s. One hour of such video requires more than 600 GByte of storage space.

[0005] One of the goals of video encoding and decoding may be the reduction of redundancy in the input video signal through compression. Compression may help reduce the aforementioned bandwidth or storage space requirements, in some cases by more than two orders of magnitude. Both lossless and lossy compression, as well as combinations thereof, may be used. Lossless compression refers to techniques where an exact replica of the original signal can be reconstructed from a compressed original signal. When using lossy compression, the reconstructed signal may not be identical to the original signal, but the distortion between the original and reconstructed signals is small enough to make the reconstructed signal useful for the intended application. For video, lossy compression has been widely adopted. The amount of acceptable distortion depends on the application, for example, users of a particular consumer streaming application may tolerate higher distortion than users of a television distribution application. The achievable compression ratio may reflect that a higher tolerable / acceptable distortion can result in a higher compression ratio.

[0006] Video encoders and decoders may utilize techniques from several broad categories, including, for example, motion compensation, transform, quantization, and entropy coding.

[0007] Video codec techniques can include a technique known as intra-coding. In intra-coding, sample values ​​are represented without reference to samples or other data from previously reconstructed reference pictures. In some video codecs, pictures are spatially subdivided into blocks of samples. If all blocks of samples are coded in intra mode, the picture may be an intra picture. Intra pictures and derivatives of intra pictures, such as independent decoder refresh pictures, may be used to reset the decoder state and thus may be used as the first picture in a coded video bitstream and video session or as a still image. Samples of an intra block may be subjected to a transform, and the transform coefficients may be quantized prior to entropy coding. Intra prediction may be a technique that minimizes sample values ​​in the pre-transform domain. In some cases, the smaller the DC value after the transform and the smaller the AC coefficients, the fewer bits are required at a given quantization step size to represent the block after entropy coding.

[0008] Conventional intra prediction, as known for example from MPEG-2 generation coding techniques, does not use intra prediction. However, some newer video compression techniques include techniques that attempt to do so from surrounding sample data and / or metadata obtained during encoding / decoding of blocks of data that are spatially nearby and preceding in decoding order. Such techniques are hereafter referred to as "intra prediction" techniques. It should be noted that in at least some cases, intra prediction uses only reference data from the current picture being reconstructed, and not from reference pictures.

[0009] Intra prediction can take many different forms. When two or more of such techniques may be used in a given video coding technique, the technique in use may be coded as an intra prediction mode. In certain cases, the mode may have sub-modes and / or parameters, which may be coded separately or included in the mode codeword. Which codeword is used for a given mode / sub-mode / parameter combination may affect the coding efficiency gains via intra prediction, as may the entropy coding technique used to convert the codeword into a bitstream.

[0010] Certain modes of intra prediction were introduced in H.264, improved in H.265, and further refined with new coding techniques such as the Joint Exploration Model (JEM), Versatile Video Coding (VVC), and Benchmark Set (BMS). A predictor block can be formed using neighboring sample values ​​belonging to already available samples. The sample values ​​of the neighboring samples are replicated in the predictor block according to the direction. The reference to the direction in use can be coded in the bitstream or it can be predicted itself.

[0011] Motion compensation may be a lossy compression technique, in which blocks of sample data from a previously reconstructed picture or part thereof (reference picture) are spatially shifted in a direction indicated by a motion vector (hereinafter MV) and then used to predict a newly reconstructed picture or part of a picture. In some cases, the reference picture may be the same as the picture currently being reconstructed. The MV may have two dimensions X and Y, or three dimensions, the third dimension being an indication of the reference picture being used (the latter may indirectly be the temporal dimension).

[0012] In some video compression techniques, the MV applicable to a particular region of sample data may be predicted from other MVs, e.g., MVs associated with another region of sample data that is spatially adjacent to the region under reconstruction and precedes that MV in decoding order. Doing so can substantially reduce the amount of data required to encode the MV, thereby eliminating redundancy and increasing compression. For example, when encoding an input video signal derived from a camera (known as natural video), MV prediction can work effectively because there is a statistical likelihood that regions larger than the region to which a single MV is applicable will move in similar directions and therefore, in some cases, can be predicted using similar motion vectors derived from MVs of nearby regions. This makes the MV found for a given region similar or the same as the MV predicted from the surrounding MVs and, after entropy encoding, can be represented with fewer bits than would be used to directly encode the MV. In some cases, MV prediction can be an example of lossless compression of a signal (i.e., MV) derived from the original signal (i.e., sample stream). In other cases, the MV prediction itself may be lossy, e.g., due to rounding errors when computing a predictor from several surrounding MVs.

[0013] Various MV prediction mechanisms are described in H.265 / HEVC (ITU-T Rec. H.265, High Efficiency Video Coding, December 2016). In this specification, among the many MV prediction mechanisms provided by H.265, a technique called "spatial merging" is described.

[0014] Referring to FIG. 1, a current block (101) contains samples found by the encoder during a motion search process to be predictable from a previous block of the same size but spatially shifted. Instead of directly encoding its MV, the MV can be derived from metadata associated with one or more reference pictures, e.g., the most recent reference picture (in decoding order), using the MV associated with any one of five surrounding samples, denoted A0, A1, and B0, B1, B2 (102-106, respectively). In H.265, MV prediction can use a predictor from the same reference picture that neighboring blocks use. Summary of the Invention [Means for solving the problem]

[0015] According to an example embodiment, a method of video decoding performed in a video decoder includes receiving an encoded video bitstream including a current picture and at least one syntax element corresponding to a transform coefficient of a transform block in the current picture. The method further includes determining an offset value based on an output of a monotonically non-decreasing f(x) function performed on a sum (x) of a group of partially reconstructed transform coefficients. The method further includes determining a context model index based on a sum of the determined offset value and a base value. The method further includes selecting a context model from a plurality of context models for the at least one syntax element of the current transform coefficient based on the determined context model index.

[0016] According to an exemplary embodiment, a method of video decoding performed in a video decoder includes receiving an encoded video bitstream including a current picture and at least one syntax element corresponding to a transform coefficient of a transform block in the current picture. The method further includes determining, for each context model region from a plurality of context model regions, an output of a monotonically non-decreasing function performed on a sum (x) of a group of partially reconstructed transform coefficients and a number of context models associated with the respective context model region. The method further includes determining a context model index based on the output of the monotonically non-decreasing function of each context model region. The method further includes selecting, for the at least one syntax element of the current transform coefficient, a context model from the plurality of context models based on the determined context model index.

[0017] According to an example embodiment, a video decoder for video decoding includes a processing circuit configured to receive an encoded video bitstream including a current picture and at least one syntax element corresponding to a transform coefficient of a transform block in the current picture. The processing circuit is further configured to determine an offset value based on an output of a monotonically non-decreasing f(x) function performed on a sum (x) of a group of partially reconstructed transform coefficients. The processing circuit is further configured to determine a context model index based on a sum of the determined offset value and a base value. The processing circuit is further configured to select a context model from a plurality of context models for the at least one syntax element of the current transform coefficient based on the determined context model index.

[0018] According to an example embodiment, a video decoder apparatus for video decoding includes a processing circuit configured to receive an encoded video bitstream including a current picture and at least one syntax element corresponding to a transform coefficient of a transform block in the current picture. The processing circuit is further configured to determine, for each context model region from the plurality of context model regions, an output of a monotonically non-decreasing function performed on a sum (x) of a group of partially reconstructed transform coefficients and a number of context models associated with the respective context model region. The processing circuit is further configured to determine a context model index based on the output of the monotonically non-decreasing function of each context model region. The processing circuit is further configured to select a context model from the plurality of context models for the at least one syntax element of the current transform coefficient based on the determined context model index.

[0019] Further features, nature and various advantages of the disclosed subject matter will become more apparent from the following detailed description and the accompanying drawings. [Brief description of the drawings]

[0020] [Figure 1] FIG. 2 is a schematic diagram of a current block and its surrounding spatial merging candidates in one example. [Diagram 2] FIG. 1 is a schematic diagram of a simplified block diagram of a communication system according to one embodiment. [Diagram 3] FIG. 1 is a schematic diagram of a simplified block diagram of a communication system according to one embodiment. [Figure 4] FIG. 2 is a schematic diagram of a simplified block diagram of a decoder according to one embodiment. [Diagram 5] FIG. 2 is a schematic diagram of a simplified block diagram of an encoder according to one embodiment. [Figure 6] 4 shows a block diagram of an encoder according to another embodiment; [Figure 7] 4 shows a block diagram of a decoder according to another embodiment; [Figure 8A] FIG. 2 illustrates an exemplary context-based adaptive binary arithmetic coding (CABAC) based entropy encoder according to one embodiment. [Figure 8B] FIG. 2 illustrates an exemplary CABAC-based entropy decoder according to one embodiment. [Figure 9] 1 illustrates an example of a sub-block scan order according to one embodiment. [Figure 10] FIG. 2 illustrates an example of a sub-block scanning process in which different types of syntax elements for transform coefficients are generated, according to one embodiment. [Figure 11] 13 shows an example of a local template used for context selection of the current coefficient. [Figure 12] Indicates the diagonal position of a coefficient or coefficient level within a coefficient block. [Figure 13] FIG. 1 illustrates a context index calculation for a luma component according to one embodiment. [Figure 14] FIG. 1 illustrates a context index calculation for a luma component according to one embodiment. [Figure 15] FIG. 1 illustrates a context index calculation for a luma component according to one embodiment. [Figure 16] 1 is a flowchart outlining an entropy decoding process according to one embodiment. [Figure 17] 1 is a flowchart outlining an entropy decoding process according to one embodiment. [Figure 18] FIG. 1 is a schematic diagram of a computer system according to one embodiment. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0021] FIG. 2 illustrates a simplified block diagram of a communication system (200) according to an embodiment of the present disclosure. The communication system (200) includes a plurality of terminal devices capable of communicating with each other, for example, via a network (250). For example, the communication system (200) includes a first pair of terminal devices (210) and (220) interconnected via the network (250). In the example of FIG. 2, the first pair of terminal devices (210) and (220) perform a unidirectional transmission of data. For example, the terminal device (210) may encode video data (e.g., a stream of video pictures captured by the terminal device (210)) for transmission to another terminal device (220) via the network (250). The encoded video data may be transmitted in the form of one or more encoded video bitstreams. The terminal device (220) may receive the encoded video data from the network (250), decode the encoded video data to reconstruct the video pictures, and display the video pictures according to the reconstructed video data. One-way data transmission may be common, such as in media serving applications.

[0022] In another example, the communication system (200) includes a second pair of terminal devices (230) and (240) performing bidirectional transmission of encoded video data, such as may occur during a video conference. For the bidirectional transmission of data, in one example, each of the terminal devices (230) and (240) may encode video data (e.g., a stream of video pictures captured by the terminal device) for transmission to the other of the terminal devices (230) and (240) over the network (250). Each of the terminal devices (230) and (240) may also receive the encoded video data transmitted by the other of the terminal devices (230) and (240), decode the encoded video data to recover the video pictures, and display the video pictures on an accessible display device according to the recovered video data.

[0023] In the example of FIG. 2, the terminal devices (210), (220), (230), and (240) may be depicted as a server, a personal computer, and a smartphone, although the principles of the present disclosure need not be so limited. Embodiments of the present disclosure find use with laptop computers, tablet computers, media players, and / or dedicated video conferencing equipment. The network (250) represents any number of networks that convey encoded video data between the terminal devices (210), (220), (230), and (240), including, for example, wired and / or wireless communication networks. The communication network (250) may exchange data over circuit-switched and / or packet-switched channels. Representative networks include telecommunications networks, local area networks, wide area networks, and / or the Internet. For purposes of this discussion, the architecture and topology of the network (250) may not be important to the operation of the present disclosure unless otherwise described herein below.

[0024] 3 illustrates the arrangement of a video encoder and a video decoder in a streaming environment as an example of an application of the disclosed subject matter. The disclosed subject matter is equally applicable to other video-enabled applications including, for example, video conferencing, digital television, and storage of compressed video on digital media including CDs, DVDs, memory sticks, etc.

[0025] The streaming system may include a video source (301) and a capture subsystem (313) that may include, for example, a digital camera that creates, for example, a stream of uncompressed video pictures (302). In one example, the stream of video pictures (302) includes samples taken by a digital camera. The stream of video pictures (302), depicted as a thick line to emphasize the high amount of data compared to the encoded video data (304) (or encoded video bitstream), may be processed by an electronic device (320) that includes a video encoder (303) coupled to the video source (301). The video encoder (303) 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 (304) (or encoded video bitstream (304)), depicted as a thin line to emphasize the lower amount of data compared to the stream of video pictures (302), may be stored on a streaming server (305) for future use. One or more streaming client subsystems, such as the client subsystems (306) and (308) of FIG. 3, can access the streaming server (305) to obtain copies (307) and (309) of the encoded video data (304). The client subsystem (306) can include a video decoder (310), for example, in an electronic device (330). The video decoder (310) decodes an input copy (307) of the encoded video data and creates an output stream (311) of video pictures that can be rendered on a display (312) (e.g., a display screen) or other rendering device (not shown). In some streaming systems, the encoded video data (304), (307), and (309) (e.g., a video bitstream) can be encoded according to a particular video encoding / compression standard, such as ITU-T Recommendation H.265. In one example, a video coding standard under development is informally known as Versatile Video Coding (VVC).The disclosed subject matter may be used in the context of a VVC.

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

[0027] 4 shows a block diagram of a video decoder (410) according to one embodiment of the present disclosure. The video decoder (410) may be included in an electronic device (430). The electronic device (430) may include a receiver (431) (e.g., a receiving circuit). The video decoder (410) may be used in place of the video decoder (310) of the example of FIG. 3.

[0028] The receiver (431) may receive one or more encoded video sequences to be decoded by the video decoder (410), in the same or other embodiments, one encoded video sequence at a time, with the decoding of each encoded video sequence being independent of the other encoded video sequences. The encoded video sequences may be received from a channel (401), which may be a hardware / software link to a storage device that stores the encoded video data. The receiver (431) may receive the encoded video data together with other data, e.g., encoded audio data and / or auxiliary data streams, that may be forwarded to a respective using entity (not shown). The receiver (431) may separate the encoded video sequences from the other data. To combat network jitter, a buffer memory (415) may be coupled between the receiver (431) and the entropy decoder / parser (420) (hereinafter "parser (420)"). In certain applications, the buffer memory (415) is part of the video decoder (410). In other cases, it may be external to the video decoder (410) (not shown). In still others, there may be a buffer memory (not shown) external to the video decoder (410), for example to combat network jitter, and another buffer memory (415) internal to the video decoder (410), for example to handle playback timing. When the receiver (431) is receiving data from a store / forward device of sufficient bandwidth and controllability, or from an isosynchronous network, the buffer memory (415) may not be needed or may be small. For use with best-effort packet networks such as the Internet, a buffer memory (415) may be needed, may be relatively large, may be advantageously adaptively sized, and may be implemented at least in part in an operating system or similar element (not shown) external to the video decoder (410).

[0029] The video decoder (410) may include a parser (420) for reconstructing symbols (421) from the encoded video sequence. These categories of symbols include information used to manage the operation of the video decoder (410) and potentially information for controlling a rendering device such as a rendering device (412) (e.g., a display screen) that is not an integral part of the electronic device (430) but may be coupled to the electronic device (430) as shown in FIG. 4. The control information for the rendering device(s) may be in the form of supplemental enhancement information (SEI message) or video usability information (VUI) parameter set fragments (not shown). The parser (420) may parse / entropy decode the received encoded video sequence. The encoding of the encoded 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-dependent, etc. The parser (420) may extract from the coded video sequence at least one set of subgroup parameters for a subgroup of pixels in the video decoder based on at least one parameter corresponding to the group. The subgroups may include groups of pictures (GOPs), pictures, tiles, slices, macroblocks, coding units (CUs), blocks, transform units (TUs), prediction units (PUs), etc. The entropy decoder / parser (420) may also extract from the coded video sequence information such as transform coefficients, quantizer parameter values, motion vectors, etc.

[0030] The parser (420) may perform entropy decoding / syntax parsing operations on the video sequence received from the buffer memory (415) to produce symbols (421).

[0031] The reconstruction of the symbols (421) can involve a number of different units, depending on the type of encoded video picture or part thereof (inter-picture and intra-picture, inter-block and intra-block, etc.), and other factors. Which units are involved and how can be controlled by subgroup control information parsed from the encoded video sequence by the parser (420). The flow of such subgroup control information between the parser (420) and the following units is not depicted for clarity.

[0032] Beyond the functional blocks already mentioned, the video decoder (410) 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, the following conceptual subdivision into functional units is appropriate:

[0033] The first unit is a scalar / inverse transform unit (451), which receives quantized transform coefficients as well as control information from the parser (420) including the transform to use, block size, quantization factor, quantization scaling matrix, etc. as symbols (421). The scalar / inverse transform unit (451) may output blocks comprising sample values ​​that may be input to an aggregator (455).

[0034] In some cases, the output samples of the scaler / inverse transform (451) may relate to intra-coded blocks, i.e., 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 an intra-picture prediction unit (452). In some cases, the intra-picture prediction unit (452) generates a block of the same size and shape as the block being reconstructed using surrounding already reconstructed information fetched from a current picture buffer (458). The current picture buffer (458), for example, buffers the partially reconstructed and / or fully reconstructed current picture. The aggregator (455) adds, possibly on a sample-by-sample basis, the prediction information generated by the intra-prediction unit (452) to the output sample information provided by the scaler / inverse transform unit (451).

[0035] In other cases, the output samples of the scalar / inverse transform unit (451) may relate to an inter-coded, potentially motion-compensated block. In such cases, the motion compensated prediction unit (453) may access the reference picture memory (457) to fetch samples used for prediction. After motion compensating the fetched samples according to the symbols (421) associated with the block, these samples may be added to the output of the scalar / inverse transform unit (451) by the aggregator (455) to generate output sample information (in this case referred to as residual samples or residual signals). The addresses in the reference picture memory (457) from which the motion compensated prediction unit (453) fetches the prediction samples may be controlled by a motion vector and are available to the motion compensated prediction unit (453) in the form of a symbol (421) that 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 (457) when sub-sample accurate motion vectors are used, motion vector prediction mechanisms, etc.

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

[0037] The output of the loop filter unit (456) may be a sample stream that can be output to the render device (412) as well as stored in a reference picture memory (457) for use in future inter-picture prediction.

[0038] Once a particular coded picture is fully reconstructed, it can 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 (420)), the current picture buffer (458) can become part of the reference picture memory (457), and a new current picture buffer can be reallocated before beginning reconstruction of the next coded picture.

[0039] The video decoder (410) may perform decoding operations according to a given video compression technique of a standard, such as ITU-T Rec. H.265. The encoded video sequence may comply with a syntax specified by the video compression technique or standard used in the sense that the encoded video sequence complies with both the syntax of the video compression technique or standard and the profile documented in the video compression technique or standard. Specifically, a profile may select a particular tool as the only tool available under that profile from all tools available in the video compression technique or standard. Also required for compliance is that the complexity of the encoded video sequence is within a range 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 by a hypothetical reference decoder (HRD) specification and HRD buffer management metadata conveyed in the encoded video sequence.

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

[0041] 5 shows a block diagram of a video encoder (503) according to one embodiment of the present disclosure. The video encoder (503) is included in an electronic device (520). The electronic device (520) includes a transmitter (540) (e.g., a transmission circuit). The video encoder (503) can be used in place of the example video encoder (303) of FIG.

[0042] The video encoder (503) can receive video samples from a video source (501) (not part of the electronic device (520) in the example of FIG. 5) that can capture video images to be encoded by the video encoder (503). In other examples, the video source (501) is part of the electronic device (520).

[0043] The video source (501) may provide a source video sequence to be encoded by the video encoder (503) 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 serving system, the video source (501) may be a storage device that stores previously prepared video. In a video conferencing system, the video source (501) may be a camera that captures local image information as a video sequence. The video data may be provided as a number of separate pictures that give motion when viewed in sequence. The pictures themselves may be organized as a spatial array of pixels, each of which may contain one or more samples, depending on the sampling structure, color space, etc., in use. Those skilled in the art may easily understand the relationship between pixels and samples. The following description focuses on samples.

[0044] According to one embodiment, the video encoder (503) may encode and compress pictures of a source video sequence into an encoded video sequence (543) in real-time or under any other time constraint required by the application. Enforcing an appropriate encoding rate is one function of the controller (550). In some embodiments, the controller (550) controls and is functionally coupled to other functional units as described below. For clarity, couplings are not depicted. Parameters set by the controller (550) may include rate control related parameters (picture skip, quantizer, lambda value for rate distortion optimization techniques, etc.), picture size, Group of Pictures (GOP) layout, maximum motion vector search range, etc. The controller (550) may be configured to have other appropriate functions for the video encoder (503) optimized for a particular system design.

[0045] In some embodiments, the video encoder (503) is configured to operate in an encoding loop. As an oversimplified explanation, in one example, the encoding loop can include a source coder (530) (e.g., responsible for generating symbols, such as a symbol stream, based on an input picture to be encoded and a reference picture) and a (local) decoder (533) built into the video encoder (503). The decoder (533) reconstructs the symbols to create sample data in a similar manner that the (remote) decoder also does (because in the video compression techniques contemplated in the disclosed subject matter, any compression between the symbols and the encoded video bitstream is lossless). The reconstructed sample stream (sample data) is input to a reference picture memory (534). The decoding of the symbol stream results in a bit-exact result regardless of the location of the decoder (local or remote), so the contents in the reference picture memory (534) are also bit-exact between the local and remote encoders. In other words, the prediction part of the encoder "sees" exactly the same sample values ​​as the reference picture samples that the decoder "sees" when using the prediction during decoding. This basic principle of reference picture synchrony (and the drift that occurs when synchrony cannot be maintained, e.g., due to channel errors) is also used in several related technologies.

[0046] The operation of the "local" decoder (533) may be the same as that of a "remote" decoder, such as the video decoder (410), which is described in detail above in connection with Figure 4. However, with brief reference also to Figure 4, symbols may be available, and the encoding / decoding of the symbols into an encoded video sequence by the entropy coder (545) and parser (420) may be lossless, and the entropy decoding portion of the video decoder (410), including the buffer memory (415) and parser (420), may not be fully implemented in the local decoder (533).

[0047] An observation that can be made at this point is that any decoder techniques other than analysis / entropy decoding present in a decoder must necessarily be present in a corresponding encoder in substantially identical functional form. For this reason, the disclosed subject matter focuses on the decoder operation. A description of the encoder techniques can be omitted, since they are the inverse of the decoder techniques, which have been described generically. Only in certain areas are more detailed descriptions necessary, and are provided below.

[0048] In operation, in some examples, the source coder (530) 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 (532) 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.

[0049] The local video decoder (533) may decode the encoded video data of pictures that may be designated as reference pictures based on the symbols created by the source coder (530). The operation of the encoding engine (532) may advantageously be a lossy process. If the encoded video data can be decoded in a video decoder (not shown in FIG. 5), the reconstructed video sequence may be a replica of the source video sequence, usually with some errors. The local video decoder (533) may replicate the decoding process that may be performed by the video decoder on the reference pictures and store the reconstructed reference pictures in a reference picture cache (534). In this way, the video encoder (503) may locally store replicas of reconstructed reference pictures that have common content as reconstructed reference pictures obtained by the far-end video decoder (without transmission errors).

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

[0051] The controller (550) may manage the encoding operations of the source coder (530), including, for example, setting the parameters and subgroup parameters used to encode the video data.

[0052] The output of all the aforementioned functional units may undergo entropy coding in an entropy coder (545), which converts the symbols produced by the various functional units into an encoded video sequence by losslessly compressing the symbols according to techniques such as Huffman coding, variable length coding, or arithmetic coding.

[0053] The transmitter (540) may buffer the encoded video sequence created by the entropy coder (545) and prepare it for transmission over a communication channel (560), which may be a hardware / software link to a storage device that stores the encoded video data. The transmitter (540) may merge the encoded video data from the video coder (503) with other data to be transmitted, such as encoded audio data and / or auxiliary data streams (sources not shown).

[0054] The controller (550) may manage the operation of the video encoder (503). During encoding, the controller (550) may assign a particular encoded picture type to each encoded picture, which may affect the coding technique that may be applied to each picture. For example, pictures may often be assigned as any of the following picture types:

[0055] 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, such as, for example, Independent Decoder Refresh ("IDR") Pictures. Those skilled in the art are aware of these variations of I-pictures and their respective uses and characteristics.

[0056] 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.

[0057] Bidirectionally predicted pictures (B-pictures) may be those that can be coded and decoded using intra- or inter-prediction, which uses up to two motion vectors and reference indices to predict the sample values ​​of each block. Similarly, multiple predicted pictures can use more than two reference pictures and associated metadata for the reconstruction of a single block.

[0058] A source picture may generally be spatially subdivided into multiple sample blocks (e.g., blocks of 4x4, 8x8, 4x8, or 16x16 samples, respectively) and coded block by block. A block may be predictively coded with reference to other (already coded) blocks, as determined by a coding assignment applied to the respective picture of the block. For example, a block 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). A pixel block of a P picture may be predictively coded via spatial prediction or via temporal prediction with reference to one previously coded reference picture. A block 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.

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

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

[0061] A video may be captured as multiple source pictures (video pictures) in 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 other) between pictures. In one example, a particular picture being coded / decoded, called a current picture, is divided into blocks. When a block in the current picture is similar to a reference block in a previously coded and still buffered reference picture in the video, the block in the current picture can be coded by a vector called a motion vector. The 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.

[0062] In some embodiments, bi-prediction techniques can be used for inter-picture prediction. According to bi-prediction techniques, two reference pictures, such as a first reference picture and a second reference picture, are used, both of which are prior to the decoding order of the current picture in the video (but the display order may be in the past and future, respectively). A block in the current picture can 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 can be predicted by a combination of the first reference block and the second reference block.

[0063] Furthermore, to improve coding efficiency, merge mode techniques can be used for inter-picture prediction.

[0064] 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 divided 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 can be recursively quad-tree partitioned into one or more coding units (CUs). For example, a CTU of 64×64 pixels can be partitioned 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 the prediction type of the CU, such as an inter prediction type or an intra prediction type. The CU is partitioned into one or more prediction units (PUs) depending on the temporal and / or spatial predictability. Generally, each PU includes a luma prediction block (PB) and two chroma PBs. In one embodiment, prediction operations in encoding (encoding / decoding) are performed in units of prediction blocks. Taking 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.

[0065] 6 shows a diagram of a video encoder (603) according to another embodiment of the present disclosure. The video encoder (603) is configured to receive a processed block (e.g., a predictive block) of sample values ​​in a current video picture in a sequence of video pictures and to encode the processed block into an encoded picture that is part of an encoded video sequence. In one example, the video encoder (603) is used in place of the video encoder (303) of the example of FIG. 3.

[0066] In an HEVC example, the video encoder (603) receives a matrix of sample values ​​for a processing block, such as a predictive block of 8×8 samples. The video encoder (603) determines whether the processing block is best coded using intra mode, inter mode, or bi-predictive mode, for example using rate-distortion optimization. If the processing block is coded in intra mode, the video encoder (603) may use intra prediction techniques to code the processing block into a coded picture, and when the processing block is coded in inter mode or bi-predictive mode, the video encoder (603) may use inter prediction or bi-predictive techniques, respectively, to code the processing block into a coded picture. In certain video coding techniques, the merge mode may be an inter-picture prediction submode in which a motion vector is derived from one or more motion vector predictors without the benefit of coded motion vector components outside the predictors. In certain other video coding techniques, there may be motion vector components applicable to the current block. In one example, the video encoder (603) includes other components, such as a mode decision module (not shown) for determining the mode of the processing block.

[0067] In the example of FIG. 6, the video encoder (603) includes an inter-encoder (630), an intra-encoder (622), a residual calculator (623), a switch (626), a residual encoder (624), a general controller (621), and an entropy encoder (625), which are coupled together as shown in FIG.

[0068] The inter-encoder (630) is configured to receive samples of a current block (e.g., a processing block), compare the block to one or more reference blocks in reference pictures (e.g., blocks in previous and subsequent pictures), generate inter-prediction information (e.g., a description of redundant information through inter-coding techniques, motion vectors, merge mode information), and calculate an inter-prediction result (e.g., a predictive block) based on the inter-prediction information using any suitable technique. In some examples, the reference picture is a decoded reference picture that is decoded based on the coded video information.

[0069] The intra encoder (622) is configured to receive samples of a current block (e.g., a processing block), possibly compare the block with blocks already coded in the same picture, generate quantized coefficients after transformation, and possibly also generate intra prediction information (e.g., intra prediction direction information according to one or more intra coding techniques). In one example, the intra encoder (622) calculates an intra prediction result (e.g., a prediction block) based on the intra prediction information and a reference block in the same picture.

[0070] The general controller (621) is configured to determine general control data and control other components of the video encoder (603) based on the general control data. In one example, the general controller (621) determines a mode of the block and provides a control signal to the switch (626) based on the mode. For example, when the mode is an intra mode, the general controller (621) controls the switch (626) to select an intra mode result to be used by the residual calculator (623) and controls the entropy encoder (625) to select intra prediction information to be included in the bitstream, and when the mode is an inter mode, the general controller (621) controls the switch (626) to select an inter prediction result to be used by the residual calculator (623) and controls the entropy encoder (625) to select inter prediction information to be included in the bitstream.

[0071] The residual calculation unit (623) calculates the difference (residual data) between the received block and a prediction result selected from the intra-encoder (622) or the inter-encoder (630). The residual encoder (624) is configured to operate on the residual data and encode the residual data to generate transform coefficients. In one example, the residual encoder (624) is configured to transform the residual data from the spatial domain to the frequency domain and generate transform coefficients. The transform coefficients are then subjected to a quantization process to obtain quantized transform coefficients. In various embodiments, the video encoder (603) also includes a residual decoder (628). The residual decoder (628) is configured to perform an inverse transform and generate decoded residual data. The decoded residual data may be suitably used by the intra-encoder (622) and the inter-encoder (630). For example, the inter-encoder (630) may generate decoded blocks based on the decoded residual data and the inter-prediction information, and the intra-encoder (622) may generate decoded blocks based on the decoded residual data and the intra-prediction information. In some examples, the decoded blocks may be appropriately processed to generate a decoded picture, which may be buffered in a memory circuit (not shown) and used as a reference picture.

[0072] The entropy encoder (625) is configured to format the bitstream to include the encoded block. The entropy encoder (625) is configured to include various information in accordance with an appropriate standard, such as the HEVC standard. In one example, the entropy encoder (625) is configured to include general control data, selected prediction information (e.g., intra-prediction information or inter-prediction information), residual information, and other appropriate information in the bitstream. It should be noted that, according to the disclosed subject matter, when encoding a block in a merged sub-mode of either the inter-mode or the bi-prediction mode, the residual information is not present.

[0073] 7 shows a diagram of a video decoder (710) according to another embodiment of the present disclosure. The video decoder (710) is configured to receive encoded pictures that are part of an encoded video sequence and decode the encoded pictures to generate reconstructed pictures. In one example, the video decoder (710) is used in place of the video decoder (310) of the example of FIG. 3.

[0074] In the example of FIG. 7, the video decoder (710) includes an entropy decoder (771), an inter-decoder (780), a residual decoder (773), a reconstruction module (774), and an intra-decoder (772), coupled together as shown in FIG.

[0075] The entropy decoder (771) may be configured to reconstruct from the coded picture certain symbols representing syntax elements that make up the coded picture. Such symbols may include, for example, prediction information (e.g., intra- or inter-prediction information, etc.) that may identify the mode in which the block is coded (e.g., intra- or inter-mode, the latter two being bi-prediction modes, merged submodes, or another submode), certain samples or metadata used for prediction by the intra-decoder (772) or inter-decoder (780), respectively, residual information, e.g., in the form of quantized transform coefficients, etc. In one example, if the prediction mode is an inter- or bi-prediction mode, the inter-prediction information is provided to the inter-decoder (780), and if the prediction type is an intra-prediction type, the intra-prediction information is provided to the intra-decoder (772). The residual information may undergo inverse quantization and is provided to the residual decoder (773).

[0076] The inter decoder (780) is configured to receive the inter prediction information and to generate inter prediction results based on the inter prediction information.

[0077] The intra decoder (772) is configured to receive intra prediction information and to generate a prediction result based on the intra prediction information.

[0078] The residual decoder (773) is configured to perform inverse quantization to extract inverse quantized transform coefficients and process the inverse quantized transform coefficients to transform the residual from the frequency domain to the spatial domain. The residual decoder (773) may also require certain control information (to include quantizer parameters (QP)), which may be provided by the entropy decoder (771) (the data path not shown as this may be low-volume control information only).

[0079] The reconstruction module (774) is configured to combine, in the spatial domain, the residual as output by the residual decoder (773) and the prediction result (possibly as output by an inter- or intra-prediction module) to form a reconstructed block that may be part of a reconstructed picture, which may be part of a reconstructed video. It should be noted that other suitable operations, such as deblocking operations, may be performed to improve visual quality.

[0080] It should be noted that the video encoders (303), (503), and (603) and the video decoders (310), (410), and (710) may be implemented using any suitable technology. In one embodiment, the video encoders (303), (503), and (603) and the video decoders (310), (410), and (710) may be implemented using one or more integrated circuits. In other embodiments, the video encoders (303), (503), and (603) and the video decoders (310), (410), and (710) may be implemented using one or more processors executing software instructions.

[0081] Entropy coding may be performed in the final stage of video coding (or the first stage of video decoding) after the video signal has been reduced to a set of syntax elements. Entropy coding may be a lossless compression scheme that uses statistical properties to compress data such that the number of bits used to represent the data is logarithmically proportional to the probability of the data. For example, by performing entropy coding over a set of syntax elements, bits representing the syntax elements (called bins) may be converted into fewer bits (called coded bits) in the bitstream. Context-based adaptive binary arithmetic coding (CABAC) is a form of entropy coding. In CABAC, a context model that provides a probability estimate may be determined for each bin in a set of bins based on the context associated with the respective bin. A binary arithmetic coding process may then be performed using the probability estimates to code the sequence of bins into coded bits in the bitstream. In addition, the context model is updated with new probability estimates based on the coded bins.

[0082] FIG. 8A illustrates an exemplary CABAC-based entropy encoder (800A) according to one embodiment. For example, the entropy encoder (800A) can be implemented in the example entropy coder (545) of FIG. 5 or the example entropy encoder (625) of FIG. 6. The entropy encoder (800A) can include a context modeler (810) and a binary arithmetic encoder (820). In one example, various types of syntax elements are provided as input to the entropy encoder (800A). For example, the bins of the binary syntax elements can be input directly to the context modeler (810), and non-binary syntax elements can be first binarized into a bin string before the bins of the bin string are input to the context modeler (810).

[0083] In one example, the context modeler (810) receives a bin of syntax elements and performs a context modeling process to select a context model for each received bin. For example, a bin of binary syntax elements of transform coefficients in a transform block is received. Thus, a context model can be determined for this bin based on, for example, the type of syntax element, the color component type of the transform component, the position of the transform coefficient, and neighboring transform coefficients previously processed. The context model can provide a probability estimate for this bin.

[0084] In one example, a set of context models can be configured for each type of syntax element. These context models can be arranged in a context model list (802) stored in a memory (801) as shown in FIG. 8A. Each entry in the context model list (802) can represent a context model. Each context model on the list can be assigned an index, called a context model index or context index. Additionally, each context model can include a probability estimate, or a parameter indicative of a probability estimate. The probability estimate can indicate the likelihood that a bin is 0 or 1. For example, during context modeling, the context modeler (810) can calculate a context index for a bin, and accordingly, a context model can be selected and assigned to the bin according to the context index from the context model list (802).

[0085] Furthermore, the probability estimates in the context model list can be initialized at the beginning of operation of the entropy encoder (800A). After a context model on the context model list (802) has been assigned to a bin and used to encode the bin, the context model can be subsequently updated according to the value of the bin with the updated probability estimate.

[0086] In one example, the binary arithmetic encoder (820) receives the bins and the context models (e.g., probability estimates) assigned to the bins and performs a binary arithmetic coding process accordingly, which generates coded bits to be transmitted in a bitstream.

[0087] FIG. 8B illustrates an exemplary CABAC-based entropy decoder (800B) according to one embodiment. For example, the entropy decoder (800B) may be implemented in the example parser (420) of FIG. 4 or the example entropy decoder (771) of FIG. 7. The entropy decoder (800B) may include a binary arithmetic decoder (830) and a context modeler (840). The binary arithmetic decoder (830) receives coded bits from a bitstream and performs a binary arithmetic decoding process to recover bins from the coded bits. The context modeler (840) may operate similarly to the context modeler (810). For example, the context modeler (840) may select a context model in a context model list (804) stored in the memory (803) and provide the selected context model to the binary arithmetic decoder (830). However, the context modeler (840) determines the context model based on the bins recovered from the binary arithmetic decoder (830). For example, based on the recovered bins, the context modeler (840) may know the type of syntax element for the next bin to be decoded, and the values ​​of previously decoded syntax elements. That information is used to determine the context model for the next bin to be decoded.

[0088] In one embodiment, the residual signal of the transform block is first transformed from the spatial domain to the frequency domain, resulting in a block of transform coefficients. Then, quantization is performed to quantize the block of transform coefficients into a block of transform coefficient levels. In various embodiments, different techniques may be used to transform the residual signal into transform coefficient levels. The block of transform coefficient levels is provided to an entropy encoder and further processed to generate syntax elements that can be encoded into bits of a bitstream. In one embodiment, the process of generating syntax elements from transform coefficient levels can be performed as follows:

[0089] A block of transform coefficient levels may first be divided into sub-blocks having a size of, for example, 4x4 positions. These sub-blocks may be processed according to a predefined scan order. FIG. 9 shows an example of a sub-block scan order, called reverse diagonal scan order. As shown, a block (910) is divided into 16 sub-blocks (901). The sub-block in the lower right corner is processed first, and the sub-block in the upper left corner is processed last. For a sub-block with all transform coefficient levels of 0, in one example, the sub-block may be skipped without processing.

[0090] For sub-blocks each having at least one non-zero transform coefficient level, four scan passes may be performed in each sub-block. During each pass, 16 positions within each sub-block may be scanned in reverse diagonal scan order. Figure 10 illustrates an example of a sub-block scan process (1000) in which different types of transform coefficient syntax elements are generated.

[0091] The 16 coefficient positions (1010) within a subblock are shown linearly at the bottom of Figure 10. The positions (1010) are numbered from 0 to 15 to reflect their respective scan orders. During a first pass, the scan positions (1010) are scanned and three types of syntax elements (1001-1003) may be generated at each scan position (1010). (i) A first type of binary syntax element (1001) (called a significance flag, denoted by sig_coeff_flag) that indicates whether the absolute transform coefficient level (denoted by absLevel) of each transform coefficient is zero or greater than zero. (ii) A second type of binary syntax element (1002) (called a parity flag and indicated by par_level_flag) that indicates the parity of the absolute transform coefficient level of the respective transform coefficient. The parity flag is generated only if the absolute transform coefficient level of the respective transform coefficient is non-zero. (iii) A third type of binary syntax element (1003) (called the greater than 1 flag and indicated by rem_abs_gt 1_flag) that indicates whether (absLevel-1)>>1 is greater than 0 for the respective transform coefficient. The greater than 1 flag is generated only if the absolute transform coefficient level of the respective transform coefficient is non-zero.

[0092] During the second pass, a fourth type binary syntax element (1004) may be generated. The fourth type syntax element (1004) is called a greater than 2 flag and is represented by rem_abs_gt 2_flag. The fourth type syntax element (1004) indicates whether the absolute transform coefficient level of the respective transform coefficient is greater than 4. The greater than 2 flag is generated only if (absLevel-1)>>1 is greater than 0 for the respective transform coefficient.

[0093] During the third pass, a fifth type non-binary syntax element (1005) may be generated. The fifth type syntax element (1005) is represented by abs_remainder and indicates a remaining value of the absolute transform coefficient level of each transform coefficient that is greater than 4. The fifth type syntax element (1005) is generated only if the absolute transform coefficient level of each transform coefficient is greater than 4.

[0094] During the fourth pass, a sixth type syntax element (1006) may be generated at each scan position (1010) having a non-zero coefficient level that indicates the sign of the respective transform coefficient level.

[0095] The various types of syntax elements (1001-1006) described above may be provided to the entropy encoder according to the order of the passes and the scan order of each pass. Different entropy coding schemes may be used to code the different types of syntax elements. For example, in one embodiment, the significance flag, the parity flag, the greater than 1 flag, and the greater than 2 flag may be coded with a CABAC-based entropy encoder as described in the example of FIG. 8A. In contrast, the syntax elements generated during the third and fourth passes may be coded with a CABAC-bypass entropy encoder (e.g., a binary arithmetic encoder with fixed probability estimates for the input bins).

[0096] Context modeling may be performed to determine a context model for a bin of some types of transform coefficient syntax elements. In one embodiment, the context model may be determined according to a local template and the diagonal position of each current coefficient (e.g., the coefficient currently being processed), possibly in combination with other factors.

[0097] FIG. 11 shows an example of a local template (1130) used for context selection of a current coefficient. The local template (1130) may cover a neighboring position or set of coefficients of the current coefficient (1120) in the coefficient block (1110). In the example of FIG. 11, the coefficient block (1110) has a size of 8×8 positions and contains coefficient levels at 64 positions. The coefficient block (1110) is divided into four sub-blocks, each having a size of 4×4 positions. In the example of FIG. 11, the local template (1130) is defined to be a five position template that covers five coefficient levels on the lower right side of the current coefficient (1120). If a reverse diagonal scan order is used for multiple passes over the scan positions in the coefficient block (1110), the neighboring positions in the local template (1130) are processed before the current coefficient (1120).

[0098] During context modeling, information at the coefficient levels in the local template (1130) may be used to determine a context model. For this purpose, a measure called the template magnitude is defined in some embodiments to measure or indicate the magnitude of the transform coefficients or transform coefficient levels in the local template (1130). The template magnitude may then be used as a basis for selecting a context model.

[0099] In one example, the template magnitude is defined to be the sum of the partially reconstructed absolute transform coefficient levels in the local template (1130), denoted by sumAbs1. The partially reconstructed absolute transform coefficient level may be determined according to the bins of the syntax elements, sig_coeff_flag, par_level_flag, and rem_abs_gt 1_flag, of the respective transform coefficient. These three types of syntax elements are obtained after a first pass of the sub-block scanning positions performed in the entropy encoder or entropy decoder. In one embodiment, the partially reconstructed absolute transform coefficient level at position (x, y) may be determined according to the following: Formula (1): absLevel1[x][y]=sig_coeff_flag[x][y]+par_level_flag[x][y]+2*rem_abs_gt 1_flag[x][y], where x and y are the coordinates relative to the upper-left corner of the coefficient block (1110), and absLevel1[x][y] represents the partially restored absolute transform coefficient level at position (x, y).

[0100] In another example, the template magnitude is defined (1130) to be the difference, indicated by tmplCpSum_1, between the sum of the partially reconstructed absolute transform coefficient levels and the number of non-zero coefficients in the local template, indicated by numSig. Thus, the difference can be determined according to: Equation (2): tmplCpSum 1=sumAbs 1-numSig.

[0101] In other examples, the template magnitude may be defined in other ways to indicate the magnitude of the transform coefficients or transform coefficient levels.

[0102] In some embodiments, to exploit correlations between transform coefficients, previously coded coefficients covered by the local template shown in Fig. 11 are used in the context selection of the current coefficient, where the position with square cross-hatching (1120) indicates the current transform coefficient position (x,y) and the positions with diagonal cross-hatching indicate its five neighbors. Let AbsLevelPass1[x][y] denote the partially reconstructed absolute level of the coefficient at position (x,y) after the first pass, d denote the diagonal position (d=x+y) of the current coefficient, and sumAbs1 denote the sum of the partially restored absolute levels AbsLevelPass1[x][y] of the coefficients covered by the local template. The syntax element AbsLevelPass 1[x][y] can be computed from the syntax elements sig_coeff_flag[xC][yC], abs_level_gtx_flag[n][0], par_level_flag[n], abs_level_gtx_flag[n][1], where abs_level_gtx_flag[n][0] and abs_level_gtx_flag[n][1] are also known as rem_abs_gt 1_flag and rem_abs_gt 2_flag, respectively, for the coefficient at position n in Figure 10.

[0103] Figure 12 shows the diagonal location of coefficients or coefficient levels in a coefficient block (1210). In one embodiment, the diagonal location of a scan position (x,y) is defined according to the following: Equation (3): d = x + y, where d represents the diagonal position, and x and y are the coordinates of the respective positions. The diagonal position d of each coefficient can be used to define different frequency regions within the coefficient block (1210) based on one or two diagonal position thresholds. As two examples, the low frequency region (1220) is defined with d<=3, while the high frequency region (1230) is defined with d>=11, as shown in FIG. 12.

[0104] In some embodiments, when encoding sig_coeff_flag[x][y] of the current coefficient, the context model index is selected depending on the value of sumAbs1 and the diagonal position d. More specifically, as shown in Figure 13 for the luma component, the context model index is determined according to: Formula (4): offset = min(sumAbs1,5) Formula (5): base = 18*max(0,state-1)+(d<2?12:(d<5?6:0)) Formula (6): ctxSig = base + offset

[0105] For a chroma component, the context model index is determined according to the following: Formula (7): offset = min(sumAbs 1, 5) Formula (8): base = 12*max(0, state-1) + (d<2?6:0) Formula (9): ctxSig = base + offset, The state specifies the scalar quantizer to be used, and the operators ? and : are defined as in the computer language C. If Dependent Quantization is enabled, the state is derived using a state transition process. Otherwise, dependent quantization is not enabled and the state is equal to 0.

[0106] In some examples, the number of context models for encoding sig_coeff_flag[x][y] is 54 for luma and 36 for chroma. Thus, the total number of context models for encoding sig_coeff_flag[x][y] is 90, which is more than 21% of the 424 context models in a standardized context modeling scheme such as VVC Draft 5.

[0107] Table 1 shows an example of the residual coding syntax: In Table 1, xC corresponds to the x coordinate of the current coefficient in the transform block, and yC corresponds to the y coordinate of the current coefficient in the transform block.

[0108] [Table 1A] [Table 1B] [Table 1C] [Table 1D]

[0109] As the number of context models increases, so does the complexity of hardware and software. Therefore, it is desirable to reduce the number of context models without sacrificing coding efficiency. In particular, it is desirable to reduce the number of context models for coding of transform coefficient significance, since the standardized context modeling method of VVC Draft 5 uses more than 21% of the 424 context models.

[0110] The embodiments of the present disclosure may be used separately or combined in any order. Moreover, each of the methods, encoders and decoders according to the embodiments of the present disclosure may be implemented by a processing circuit (e.g., one or more processors or one or more integrated circuits). In one example, the one or more processors execute a program stored in a non-transitory computer-readable medium. According to the embodiments of the present disclosure, a term block may be interpreted as a prediction block, a coding block, or a coding unit (i.e., CU).

[0111] According to some embodiments, the region is defined as a set of connected transform coefficient positions. For example, the region is a set of transform coefficient positions (x, y) such that d0 ≦ x + y < d1 for some non - negative integers d0 and d1 called position thresholds. Embodiments of the present disclosure can be applied to entropy coding techniques of a transform coefficient significance flag (sig_coeff_flag) having the following parameters: (i) N is the number of context models per region. In one exemplary embodiment, N is equal to 4. In other exemplary embodiments, N is equal to 5. (ii) d 0Y and d 1Y are diagonal position thresholds for the luma region. In one exemplary embodiment, d 0Y is 2 and d 1Y is 5. (iii) d 0C is a diagonal position threshold for the chroma region. In one exemplary embodiment, d 0C is 2. (iv) f(x) is a non - decreasing function that maps from the set of non - negative integers to the set of non - negative integers. (v) When N is 5, an embodiment of the function f(x) is defined as follows. f(x)=x-(x>>2) (vi) When N is 4, an embodiment of the function f(x) is defined as follows. f(x)=(x + 1)>>1

[0112] According to some embodiments, when encoding the sig_coeff_flag[x][y] of the current coefficient, the context model index is selected according to the value of sumAbs1 and the diagonal position d. More specifically, as shown in FIG. 14, for the luma component, the context model index is determined as follows in some embodiments: Equation (10): offset = min(f(sumAbs1), N - 1) Equation (11): base = 3*N*max(0, state - 1)+(d < d0 Y?2*N:(d <d1 Y ?N:0)) Formula (12): ctxSig = base + offset

[0113] For a chroma component, the context model index is determined according to the following: Equation (13): offset = min(f(sumAbs 1), N-1) Equation (14): Base = 2*N*max(0, state-1) + (d <d0 C ?N:0) Formula (15): ctxSig = base + offset where state specifies the scalar quantizer used when dependent quantization is enabled and the state is derived using a state transition process. When dependent quantization is not enabled, in some examples, state is equal to 0. Furthermore, in some embodiments, the function min(f(sumAbs1),N-1) can also be implemented for lower hardware complexity than f(min(sumAbs1,5)) when N is 4 or 5, as shown in FIG.

[0114] The standardized context modeling scheme in VVC Draft 5 has 90 context models for encoding the significance of transform coefficients. In an embodiment of the present disclosure, when N is equal to 5, the number of context models is reduced from 90 to 75, and when N is equal to 4, the number of context models is reduced from 90 to 60.

[0115] According to some embodiments, a monotonically non-decreasing function f(x) of non-negative integer x can be defined as follows: Equation (16):

number

number

[0116] According to some embodiments, the context region depends on the diagonal position d, so that the number of context models per region depends on the diagonal position d, further reducing the number of contexts. For example, (d <d 0Y ), (d 0Y ≦d <d 1Y ), (d 1Y ≦d <d 2Y ) are N1, N2, and N3, respectively. In particular, the number of context models can vary based on the value of d. In this case, the context model index is Equation (17): g1(x)=min(f1(x),N1-1) Equation (18): g2(x)=min(f2(x),N2-1) Equation (19): g3(x) = min(f3(x), N3-1) Equation (20): ctxSig = (N1 + N2 + N3) * max (0, state -1) + (d <d 0Y ?(N2+N3)+g1(sumAbs 1): (d <d 1Y ?N3+g2(sumAbs 1):g3(sumAbs 1))), where f1(x), f2(x), and f3(x) are monotonically non-decreasing functions of non-negative integer x. Example values ​​of N1, N2, and N3 may be integer values ​​from 1 to 16. The embodiment including equations (17)-(20) provides more flexibility by reducing the number of contexts with the same bit rate.

[0117] An alternative embodiment of the present disclosure can be applied to an entropy coding technique of the transform coefficient significance flags with the following parameters: (i) N is the number of context models per region. In this embodiment, N is equal to 4. (ii)d 0Y is the diagonal position threshold of the luma region. In this embodiment, d 0Y is 5. (iii)d0C is the diagonal position threshold of the chroma region. In this embodiment, d 0C is 2. (iv) When N is 4, a function f(x) of a non-negative integer x is defined as follows: f(x)=(x+1)>>1

[0118] According to some embodiments, when encoding sig_coeff_flag[x][y] of the current coefficient, the context model index is selected depending on sumAbs1 and the diagonal position d, and for the luma component, the context model index is determined according to: Equation (21): offset = min(f(sumAbs 1), N-1) Equation (22): Base = 2*N*max(0, state-1) + (d <d 0Y ?N:0) Formula (23): ctxSig = base + offset

[0119] For a chroma component, the context model index is determined according to the following: Equation (24): offset = min (f (sumAbs 1), N-1) Equation (25): Base = 2*N*max(0, state-1) + (d <d 0C ?N:0) Formula (26): ctxSig = base + offset where state specifies the scalar quantizer used if dependent quantization is enabled and the state is derived using a state transition process, otherwise dependent quantization is not enabled and state is equal to 0.

[0120] In some embodiments, the function min(f(sumAbs 1),N-1) can also be implemented for lower hardware complexity than f(min(sumAbs 1,5)).

[0121] The standardized context modeling scheme in VVC Draft 5 has 90 context models for encoding the significance of transform coefficients. In the alternative embodiment disclosed above (i.e., equations (21)-(26)), when N is equal to 4, the number of context models is reduced from 90 to 48.

[0122] FIG. 16 illustrates one embodiment of a process performed by a decoder, such as the video decoder (710). The process may begin at step (S1600), where an encoded video bitstream is received that includes a current picture and at least one syntax element corresponding to a transform coefficient of a transform block in the current picture. As an example, the at least one syntax element may be sig_coeff_flag. The process proceeds to step (S1602), where an offset value is determined based on an output of a monotonically non-decreasing function f(x) performed on a sum (x) of a group of partially reconstructed transform coefficients. The process proceeds to step (S1604), where a context model index is determined based on a sum of the determined offset value and a base value. As an example, the context model index may be determined according to the process illustrated in any of FIG. 14 and FIG. 15, or the alternative embodiments disclosed above (i.e., equations (21)-(26)). The process proceeds to step (S1606), where a context model is selected from a plurality of context models for the at least one syntax element of the current transform coefficient based on the determined context model index.

[0123] 17 illustrates one embodiment of a process performed by a decoder, such as the video decoder (710). The process may begin at step (S1700), where an encoded video bitstream is received that includes a current picture and at least one syntax element corresponding to a transform coefficient of a transform block in the current picture. As an example, the at least one syntax element may be sig_coeff_flag. The process proceeds to step (S1702), where, for each context model region from a plurality of context model regions, an output of a monotonically non-decreasing function performed on a sum (x) of a group of partially reconstructed transform coefficients and a number of context models associated with the respective context model region is determined. For example, the functions g1(x)=min(f1(x),N1-1), g2(x)=min(f2(x),N2-1), and g3(x)=min(f3(x),N3-1) disclosed above can be used for each context model region, with the number of context models per region (i.e., N1, N2, N3) varying based on the distance of the current coefficient from the top-left corner of the transform block. The process proceeds to step (S1704), where a context model index is determined based on the output of the monotonically non-decreasing function for each context model region. The process proceeds to step (S1706), where a context model is selected from the multiple context models for at least one syntax of the current transform coefficient based on the determined context model index.

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

[0125] Computer software can be encoded using any suitable machine or computer language that can be subject to assembly, compilation, linking, or similar mechanisms to create code containing instructions that can be executed directly or via translation, microcode execution, etc., by one or more computer central processing units (CPUs), graphics processing units (GPUs), etc.

[0126] 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.

[0127] 18 for the computer system (1800) 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 relating to any one or combination of components illustrated in the exemplary embodiment of the computer system (1800).

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

[0129] The input human interface devices may include one or more of a keyboard (1801), a mouse (1802), a trackpad (1803), a touch screen (1810), a data glove (not shown), a joystick (1805), a microphone (1806), a scanner (1807), and a camera (1808).

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

[0131] The computer system (1800) may also include human accessible storage devices and their associated media, such as optical media including CD / DVD ROM / RW (1820) with CD / DVD or similar media (1821), thumb drives (1822), removable hard drives or solid state drives (1823), legacy magnetic media such as tapes and floppy disks (not shown), specialized ROM / ASIC / PLD based devices (not shown) such as security dongles, etc.

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

[0133] The computer system (1800) may also include interfaces to one or more communication networks. 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, wireless LAN, cellular networks including global systems for 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, etc. Certain networks typically require an external network interface adapter that is attached to a particular general data port or peripheral bus (1849) (e.g., a USB port on the computer system (1800)), while others are typically integrated into the core of the computer system (1800) by connecting to a system bus as described below (e.g., an Ethernet interface to a PC computer system or a cellular network interface to a smartphone computer system, etc.). Using any of these networks, the computer system (1800) may communicate with other entities. Such communications may be one-way, receive only (e.g., television broadcast), one-way transmit only (e.g., a CANbus to a particular CANbus device), or two-way, e.g., to other computer systems using local or wide area digital networks. As noted above, specific protocols and protocol stacks may be used with each of these networks and network interfaces.

[0134] The aforementioned human interface devices, human accessible storage devices, and network interfaces may be connected to a core (1840) of the computer system (1800).

[0135] The cores (1840) may include one or more central processing units (CPUs) (1841), graphics processing units (GPUs) (1842), specialized programmable processing units in the form of field programmable gate areas (FPGAs) (1843), hardware accelerators for specific tasks (1844), and the like. These devices may connect through a system bus (1848) along with read only memory (ROM) (1845), random access memory (1846), internal mass storage devices such as internal hard drives that are not accessible to the user, SSDs, and the like (1847). In some computer systems, the system bus (1848) may be accessible in the form of one or more physical plugs to allow expansion with additional CPUs, GPUs, and the like. Peripheral devices may be connected directly to the core's system bus (1848) or through a peripheral bus (1849). Peripheral bus architectures include PCI, USB, and the like.

[0136] The CPU (1841), GPU (1842), FPGA (1843), and accelerator (1844) can execute certain instructions that, in combination, can constitute the aforementioned computer code. The computer code can be stored in ROM (1845) or RAM (1846). Transient data can also be stored in RAM (1846), while permanent data can be stored, for example, in internal mass storage (1847). Rapid storage and retrieval of any memory device can be made possible through the use of cache memory, which can be closely associated with one or more of the CPU (1841), GPU (1842), mass storage (1847), ROM (1845), RAM (1846), etc.

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

[0138] As an example, but not by way of limitation, a computer system having the architecture (1800), and in particular the core (1840), 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 the user-accessible mass storage devices introduced above, as well as media associated with specific storage of the core (1840) of a non-transitory nature, such as the core internal mass storage (1847) or ROM (1845). Software implementing various embodiments of the present disclosure can be stored in such devices and executed by the core (1840). The computer-readable media can include one or more memory devices or chips, depending on the particular needs. The software can cause the core (1840), 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 (1846) and modifying such data structures according to processes defined by the software. Additionally or alternatively, the computer system may provide functionality as a result of being logically hardwired or embodied in circuitry (e.g., accelerator 1844) that can operate in place of or together with software to perform certain processes or certain portions of certain processes described herein. References to software may include logic, and vice versa, as appropriate. References to computer-readable media may encompass circuitry (such as integrated circuits (ICs)) that stores software for execution, circuitry that embodies logic for execution, or both, as appropriate. The present disclosure encompasses any suitable combination of hardware and software. Appendix A: Acronyms JEM: joint exploration model VVC:versatile video coding BMS:benchmark set MV: Motion Vector HEVC: High Efficiency Video Coding SEI: Supplementary Enhancement Information VUI:Video Usability Information GOP: Groups of Pictures TU: Transform Units PU: Prediction Units CTU: Coding Tree Units CTB: Coding Tree Blocks PB: Prediction Blocks HRD:Hypothetical Reference Decoder SNR: Signal Noise Ratio CPU: Central Processing Units GPU: Graphics Processing Units CRT: Cathode Ray Tube LCD: Liquid-Crystal Display OLED: Organic Light-Emitting Diode CD:Compact Disc DVD: Digital Video Disc ROM: Read-Only Memory RAM: Random Access Memory ASIC: Application-Specific Integrated Circuit PLD: Programmable Logic Device LAN: Local Area Network GSM: Global System for Mobile communications LTE: Long-Term Evolution CANBus: Controller Area Network Bus USB: Universal Serial Bus PCI: Peripheral Component Interconnect FPGA: Field Programmable Gate Areas SSD: solid-state drive IC: Integrated Circuit CU: Coding Unit

[0139] While this disclosure describes several exemplary embodiments, there are modifications, permutations, and various substitute equivalents that are within the scope of the disclosure. It will thus be appreciated that those skilled in the art will be able to devise numerous systems and methods that, although not explicitly shown or described herein, embody the principles of the disclosure and are therefore within its spirit and scope.

[0140] (1) A method of video decoding performed in a video decoder, the method comprising: receiving an encoded video bitstream including a current picture and at least one syntax element corresponding to a transform coefficient of a transform block in the current picture; determining an offset value based on an output of a monotonically non-decreasing f(x) function performed on a sum (x) of a group of partially reconstructed transform coefficients; determining a context model index based on a sum of the determined offset value and a base value; and selecting a context model from a plurality of context models for the at least one syntax element of the current transform coefficient based on the determined context model index.

[0141] (2) The method of feature (1), wherein one of the base value and the offset value is determined based on the number of context models included in the plurality of context models.

[0142] (3) The method of any one of the preceding features, further comprising determining whether dependent quantization is enabled for the current coefficient, and in response to determining that dependent quantization is enabled for the current coefficient, the base value is based on a state of a quantizer.

[0143] (4) The method of any one of the preceding features, wherein the current coefficient is located in the luma domain, and the base value is based on a comparison of a distance of the current coefficient from a top-left corner of the transform block to a first diagonal position threshold.

[0144] (5) The method of feature (4), wherein the base value is further based on a comparison of the distance to a second diagonal position threshold.

[0145] (6) The method of any one of (3) to (5), wherein the current coefficient is located in a chroma domain, and the base value is based on a comparison of a distance of the current coefficient from a top-left corner of the transform block to a first diagonal position threshold.

[0146] (7) The method according to any one of features (1) to (6), wherein the monotonically non-decreasing function is defined as x-(x>>2).

[0147] (8) The method according to any one of features (1) to (6), wherein the monotonically non-decreasing function is defined as (x+1)>>1.

[0148] (9) The method of any one of features (1) to (8), wherein the current coefficient and the group of partially reconstructed transform coefficients form a template that comprises a contiguous set of transform coefficients.

[0149] (10) The method of any one of features (1) to (9), wherein at least one syntax element is a transform coefficient significance flag (sig_coeff_flag).

[0150] (11) The method of any one of features (1) to (10), wherein the bitstream includes a plurality of syntax elements including at least one syntax element, and the sum (x) of the group of partially reconstructed transform coefficients is based on one or more syntax elements from the plurality of syntax elements.

[0151] (12) A method of video decoding performed in a video decoder, the method comprising: receiving an encoded video bitstream including a current picture and at least one syntax element corresponding to a transform coefficient of a transform block in the current picture; determining, for each context model region from a plurality of context model regions, an output of a monotonically non-decreasing function performed on a sum (x) of a group of partially reconstructed transform coefficients and a number of context models associated with the respective context model region; determining a context model index based on the output of the monotonically non-decreasing function for each context model region; and selecting a context model from the plurality of context models for at least one syntax element of the current transform coefficient based on the determined context model index.

[0152] (13) The method of feature (12), wherein the step of determining the context model index is further based on a comparison of a distance of the current coefficient from a top-left corner of the transform block to a first diagonal position threshold and a second diagonal position threshold.

[0153] (14) The method of feature (12), wherein the step of determining the context model index is further based on a comparison of a distance of the current coefficient from a top left corner of the transform block and a first diagonal position.

[0154] (15) A video decoder for video decoding, comprising: a processing circuit configured to receive an encoded video bitstream including a current picture and at least one syntax element corresponding to a transform coefficient of a transform block in the current picture; determine an offset value based on an output of a monotonically non-decreasing f(x) function performed on a sum (x) of a group of partially reconstructed transform coefficients; determine a context model index based on a sum of the determined offset value and a base value; and select a context model from a plurality of context models for the at least one syntax element of the current transform coefficient based on the determined context model index.

[0155] (16) The video decoder of feature (15), wherein one of the base value and the offset value is determined based on the number of context models included in the plurality of context models.

[0156] (17) The video decoder of feature (16), wherein the processing circuit is further configured to determine whether dependent quantization is enabled for the current coefficient, and in response to a determination that dependent quantization is enabled for the current coefficient, the base value is based on a state of a quantizer.

[0157] (18) The video decoder of feature (17), wherein the current coefficient is located in the luma domain, and the base value is based on a comparison of a distance of the current coefficient from a top-left corner of the transform block to a first diagonal position threshold.

[0158] (19) The video decoder of feature (18), wherein the base value is further based on a comparison of the distance to a second diagonal position threshold.

[0159] (20) A video decoder apparatus for video decoding, comprising: a processing circuit configured to receive an encoded video bitstream including a current picture and at least one syntax element corresponding to a transform coefficient of a transform block in the current picture; determine, for each context model region from a plurality of context model regions, an output of a monotonically non-decreasing function performed on a sum (x) of a group of partially reconstructed transform coefficients and a number of context models associated with the respective context model region; determine a context model index based on the output of the monotonically non-decreasing function for each context model region; and select, for at least one syntax element of the current transform coefficient, a context model from the plurality of context models based on the determined context model index. [Explanation of symbols]

[0160] 101 Current Block 200 Communication Systems 210 Terminal Equipment 220 Terminal Equipment 230 Terminal Equipment 250 Network 301 Video Source Stream 302 Video Picture 303 Video Encoder 304 Video Data 305 Streaming Server 306 Client Subsystem 307 Video Data 313 Capture Subsystem 320 Electronic equipment 401 Channel 410 Video Decoder 412 Rendering Equipment 415 Buffer Memory 420 Parser 421 Symbols 430 Electronic equipment 431 Receiver 451 Scaler / Descaler Unit 452 Intra-picture Prediction Unit 453 Motion Compensation Prediction Unit 455 Aggregator 456 Loop Filter Unit 457 Reference Picture Memory 458 Current Picture Buffer 501 Video Sources 503 Video Encoder / Video Coder 530 Source Coder 532 encoding engine 533 Local Video Decoder 534 Reference Picture Memory 535 Predictor 540 Transmitter 543 coded video sequence 545 Entropy Coder 550 Controller 560 Communication Channels 603 Video Encoder 621 General Controller 622 Intra Encoder 623 Residual Calculation Unit 624 Residual Encoder 625 Entropy Encoder 626 Switch 628 Residual Decoder 630 InterEncoder 710 Video Decoder 771 Entropy Decoder 772 Intra Decoder 773 Residual Decoder 774 Reconstruction Module 780 Inter Decoder 800A Entropy Encoder 800B Entropy Decoder 801 Memory 802 Context Model List 803 Memory 804 Context Model List 810 Context Modeler 820 Binary Arithmetic Encoder 830 Binary Arithmetic Decoder 840 Context Modeler 1000 subblock scan processes 1130 Local Templates 1800 Computer Systems 1801 Keyboard 1802 Mouse 1803 Trackpad 1805 Joystick 1806 Mike 1807 Scanner 1808 Camera 1809 Speaker 1810 Touch Screen 1821 Medium 1822 Thumb Drive 1823 Solid State Drive 1840 Core 1843 Field Programmable Gate Area (FPGA) 1844 Accelerator 1845 Read-Only Memory (ROM) 1846 Random Access Memory (RAM) 1847 Internal mass storage 1848 System Bus 1849 Peripheral Bus

Claims

1. A method for coding a video signal, comprising: receiving an encoded video bitstream including a current picture and at least one syntax element corresponding to a transform coefficient of a transform block in the current picture; determining an offset value based on the output of a monotonically non-decreasing function (f(x)) performed on a sum (x) of a group of partially reconstructed transform coefficients; determining a context model index based on the sum of the determined offset value and a base value; selecting a context model from a plurality of context models for the at least one syntax element of a current transform coefficient based on the determined context model index; Including, one of the base value and the offset value is determined based on the number of context models included in the plurality of context models; The monotonically non-decreasing function is defined as (x+1)>>1. Video decoding methods.

2. The method comprises: determining whether dependent quantization is enabled for the current transform coefficient; The method of claim 1 , wherein, in response to the determination that dependent quantization is enabled for the current transform coefficient, the base value is based on a state of a quantizer.

3. The method described in claim 2, wherein the current transform coefficient is located in the luma domain and the base value is based on a comparison of the distance between the position of the current transform coefficient within the transform block and the upper left corner of the transform block with a first diagonal position threshold.

4. The method of claim 3, wherein the base value is further based on a comparison of the distance with a second diagonal position threshold.

5. The method described in claim 2, wherein the current transform coefficient is located in the chroma domain and the base value is based on a comparison of the distance between the position of the current transform coefficient within the transform block and the upper left corner of the transform block with a first diagonal position threshold.

6. A method described in any one of claims 1 to 5, wherein the current transform coefficients and the group of partially reconstructed transform coefficients form a template constituting a contiguous set of transform coefficients.

7. A method described in any one of claims 1 to 6, wherein the at least one syntax element is a transform coefficient significance flag (sig_coeff_flag).

8. A method described in any one of claims 1 to 7, wherein the video bitstream includes a plurality of syntax elements including the at least one syntax element, and the sum (x) of the group of partially reconstructed transform coefficients is based on one or more syntax elements from the plurality of syntax elements.

9. An apparatus configured to perform the video decoding method of any one of claims 1 to 8.

10. A computer program for causing a computer of a video decoding device to execute the video decoding method according to any one of claims 1 to 8.

11. A method for generating a data structure, comprising: receiving at least one syntax element; calculating a context model index for the syntax element; selecting a context model based on the context model index; performing a binary arithmetic coding process according to the context model to generate coded bits; generating an encoded bitstream based on the encoded bits and storing the encoded bitstream in a non-transitory computer-readable storage medium; The step of calculating the context model index comprises: determining an offset value based on the output of a monotonically non-decreasing function (f(x)) performed on a sum (x) of a group of partially reconstructed transform coefficients; determining a context model index based on the sum of the determined offset value and a base value; selecting a context model from a plurality of context models for the at least one syntax element of a current transform coefficient based on the determined context model index; Including, one of the base value and the offset value is determined based on the number of context models included in the plurality of context models; The monotonically non-decreasing function is defined as (x+1)>>1. Video coding method.

12. The method comprising: determining whether dependent quantization is enabled for the current transform coefficient; The method of claim 11 , wherein, in response to the determination that dependent quantization is enabled for the current transform coefficient, the base value is based on a state of a quantizer.

13. The method described in claim 12, wherein the current transform coefficient is located in the luma domain and the base value is based on a comparison of the distance between the position of the current transform coefficient within a transform block in the current picture and the upper left corner of the transform block with a first diagonal position threshold.

14. The method of claim 13, wherein the base value is further based on a comparison of the distance with a second diagonal position threshold.

15. The method described in claim 12, wherein the current transform coefficient is located in the chroma domain and the base value is based on a comparison of the distance between the position of the current transform coefficient within a transform block in the current picture and the upper left corner of the transform block with a first diagonal position threshold.

16. A method described in any one of claims 11 to 15, wherein the current transform coefficients and the group of partially reconstructed transform coefficients form a template constituting a contiguous set of transform coefficients.

17. A method described in any one of claims 11 to 16, wherein the at least one syntax element is a transform coefficient significance flag (sig_coeff_flag).

18. A method described in any one of claims 11 to 17, wherein the bitstream includes a plurality of syntax elements including the at least one syntax element, and the sum (x) of the group of partially reconstructed transform coefficients is based on one or more syntax elements from the plurality of syntax elements.

19. An apparatus configured to perform a video coding method according to any one of claims 11 to 18.

20. A computer program for causing a computer of a video coding device to execute the video coding method according to any one of claims 11 to 18.

21. A method of encoding a video bitstream comprising: receiving an encoded video bitstream including a current picture and at least one syntax element corresponding to transform coefficients of a transform block in the current picture; determining an offset value based on the output of a monotonically non-decreasing function (f(x)) performed on a sum (x) of a group of partially reconstructed transform coefficients; determining a context model index based on the sum of the determined offset value and a base value; selecting a context model from a plurality of context models for the at least one syntax element of the current transform coefficient based on the determined context model index; Including, one of the base value and the offset value is determined based on the number of context models included in the plurality of context models; The monotonically non-decreasing function is defined as x-(x>>2). Video decoding methods.

22. An apparatus configured to perform the video decoding method of claim 21.

23. A computer program product for causing a computer of a video decoding device to carry out the method of video decoding according to claim 21.