Method, apparatus, and computer program for reducing context models for entropy coding of transform coefficient significance flags
By optimizing context model selection for entropy coding using a monotonically non-decreasing function of partially reconstructed transform coefficients, the method addresses inefficiencies in video encoding and decoding, leading to reduced bitrate and storage requirements.
Patent Information
- Application Number
- JP2024206395
- Authority / Receiving Office
- JP · JP
- Patent Type
- Patents
- Current Assignee / Owner
- Priority Date
- 2020-06-17
- Filing Date
- 2024-11-27
- Publication Date
- 2026-01-27
- Estimated Expiration
- 2040-06-18
AI Technical Summary
Existing video encoding and decoding technologies face challenges in efficiently reducing redundancy and improving compression efficiency, particularly in intra-prediction and motion vector prediction, which affect the bitrate and storage requirements of video data.
The method involves determining an offset value based on a monotonically non-decreasing function of partially reconstructed transform coefficients to select a context model for entropy coding, optimizing the selection of context models for transform coefficient significance flags.
This approach enhances compression efficiency by reducing the bitrate and storage requirements of video data, improving the effectiveness of entropy coding in video decoding processes.
Smart Images

Figure 0007807516000007 
Figure 0007807516000008 
Figure 0007807516000009
Abstract
Description
[Technical Field]
[0001] CROSS-REFERENCE TO RELATED APPLICATIONS This disclosure claims the benefit of priority to U.S. Patent Application No. 16 / 904,000, entitled "METHOD AND APPARATUS FOR 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 related to video coding. [Background technology]
[0003] The background art discussion provided herein is intended to generally present the context for the present disclosure. The inventors' work, to the extent that it is described in this background art section, and aspects of the discussion that may not be admitted as prior art at the time of filing, are not admitted expressly or implicitly as prior art to the present disclosure.
[0004] Video encoding and decoding can be performed using inter-picture prediction with motion compensation. Uncompressed digital video can include a series of pictures, each with spatial dimensions of, for example, 1920 x 1080 luma samples and associated chroma samples. The series of pictures can have a fixed or variable picture rate (informally known as a frame rate), for example, 60 pictures per second or 60 Hz. Uncompressed video has significant bitrate requirements. For example, 1080p60 4:2:0 video (1920 x 1080 luma sample resolution at a 60 Hz frame rate) with 8 bits per sample requires a bandwidth approaching 1.5 Gbit / s. One hour of such video requires more than 600 GBytes of storage space.
[0005] One goal of video encoding and decoding is to reduce redundancy in the input video signal through compression. Compression can help reduce the aforementioned bandwidth or storage space requirements, sometimes by more than two orders of magnitude. Both lossless and lossy compression, as well as combinations of them, can be used. Lossless compression refers to techniques that allow an exact replica of the original signal to be reconstructed from a compressed version of the original signal. When lossy compression is used, the reconstructed signal may not be identical to the original signal, but the distortion between the original and reconstructed signal is small enough to make the reconstructed signal useful for its intended application. For video, lossy compression is widely adopted. The amount of acceptable distortion depends on the application; for example, users of certain consumer streaming applications may tolerate higher distortion than users of television distribution applications. The achievable compression ratio can reflect that 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 technology can include a technique known as intra-coding. In intra-coding, sample values are represented without reference to other data from samples or 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 their derivatives, such as independent decoder refresh pictures, may be used to reset the decoder state and therefore may be used as the first picture in a coded video bitstream and video session or as a still image. Samples in intra-blocks may be subjected to a transform, and the transform coefficients may be quantized before entropy coding. Intra-prediction can be a technique that minimizes sample values in the pre-transform domain. In some cases, the smaller the DC value and AC coefficients after the transform, the fewer bits required for a given quantization step size to represent the block after entropy coding.
[0008] Traditional intra-prediction, such as that known 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 the 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. Note that in at least some cases, intra-prediction uses only reference data from the current picture being reconstructed, not from reference pictures.
[0009] Intra prediction can take many different forms. When two or more such techniques can be used in a given video coding technique, the techniques in use may be coded as intra prediction modes. In certain cases, modes may have submodes and / or parameters, which may be coded separately or included in a mode codeword. The codeword used for a given mode / submode / 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, refined in H.265, and further improved 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 their direction. The reference to the direction in use can be coded in the bitstream or can itself be predicted.
[0011] Motion compensation may be a lossy compression technique in which blocks of sample data from a previously reconstructed picture or portion 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 picture portion. 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, with the third dimension being an indication of the reference picture in use (the latter may indirectly be the temporal dimension).
[0012] In some video compression techniques, the MV applicable to a particular region of sample data can be predicted from other MVs, e.g., MVs associated with another region of sample data that is spatially adjacent to the region being reconstructed 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 a similar direction and, therefore, in some cases, can be predicted using similar motion vectors derived from MVs of nearby regions. This results in the MV found for a given region being similar or identical to the MV predicted from surrounding MVs, and after entropy coding, can be represented using 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, MV prediction itself can be lossy, for example, due to rounding errors when calculating 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, we will describe a technique called "spatial merging" among the many MV prediction mechanisms provided by H.265.
[0014] Referring to Figure 1, the current block (101) contains samples found by the encoder during the motion search process to be predictable from a spatially shifted previous block of the same size. 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, and B2 (102-106, respectively). In H.265, MV prediction can use a predictor from the same reference picture used by neighboring blocks. Summary of the Invention [Means for solving the problem]
[0015] According to an example embodiment, a video decoding method 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 example embodiment, a video decoding method performed in a video decoder includes 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. The method further includes, for each context model region from a plurality of context model regions, determining 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 for each context model region. The method further includes 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.
[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 exemplary embodiment, a video decoder device 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 transform coefficients of a transform block in the current picture. The processing circuit is further configured to 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. The processing circuit is further configured to determine a context model index based on the output of the monotonically non-decreasing function for each context model region. The processing circuit is further configured to select 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.
[0019] Further features, nature and various advantages of the disclosed subject matter will become more apparent from the following detailed description and accompanying drawings. [Brief explanation of the drawings]
[0020] [Figure 1] FIG. 1 is a schematic diagram of a current block and its surrounding spatial merge candidates in one example. [Figure 2] FIG. 1 is a schematic diagram of a simplified block diagram of a communication system according to one embodiment. [Figure 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. [Figure 5] FIG. 2 is a schematic diagram of a simplified block diagram of an encoder according to one embodiment. [Figure 6] 10 shows a block diagram of an encoder according to another embodiment; [Figure 7] 10 shows a block diagram of a decoder according to another embodiment; [Figure 8A] FIG. 1 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. 10 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] 10 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. 10 illustrates a context index calculation for a luma component according to one embodiment. [Figure 14] FIG. 10 illustrates a context index calculation for a luma component according to one embodiment. [Figure 15] FIG. 10 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 INVENTION
[0021] FIG. 2 illustrates a simplified block diagram of a communication system (200) according to one embodiment of the present disclosure. The communication system (200) includes multiple terminal devices capable of communicating with each other, e.g., 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 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) that perform 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 application with laptop computers, tablet computers, media players, and / or dedicated videoconferencing 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. Exemplary 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), which may include, for example, a digital camera, that creates a stream of uncompressed video pictures (302). In one example, the stream of video pictures (302) includes samples captured by the digital camera. The stream of video pictures (302), depicted as a thick line to emphasize its high data volume 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, and may 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 its lower data volume 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 Figure 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, within an electronic device (330). The video decoder (310) decodes the 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 can be used in the context of 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) in the example of FIG. 3.
[0028] The receiver (431) may receive one or more coded video sequences to be decoded by the video decoder (410), in the same or other embodiments, one coded video sequence at a time, with the decoding of each coded video sequence being independent of the other coded video sequences. The coded video sequences may be received from a channel (401), which may be a hardware / software link to a storage device that stores the coded video data. The receiver (431) may receive the coded video data along with other data, such as coded audio data and / or auxiliary data streams, that may be forwarded to a respective using entity (not shown). The receiver (431) may separate the coded video sequences from 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, 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 symbol categories include information used to manage the operation of the video decoder (410) and, potentially, information for controlling a rendering device, such as a render 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) messages 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 variety of video coding techniques or standards, including variable-length coding, Huffman coding, arithmetic coding with or without context-sensitive coding, 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 create symbols (421).
[0031] The reconstruction of the symbols (421) can involve several different units, depending on the type of coded video picture or portion thereof (inter-picture and intra-picture, inter-block and intra-block, etc.), as well as other factors. Which units are involved and how can be controlled by subgroup control information parsed from the coded 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 described, the video decoder (410) may be conceptually subdivided into several functional units, as described below. In an actual implementation operating under commercial constraints, many of these units will 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) as symbols (421), including the transform to use, block size, quantization factor, quantization scaling matrix, etc. 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 the intra-picture prediction unit (452). In some cases, the intra-picture prediction unit (452) generates blocks of the same size and shape as the block being reconstructed using surrounding, already reconstructed information fetched from the current picture buffer (458). The current picture buffer (458), for example, buffers partially reconstructed and / or fully reconstructed current pictures. The aggregator (455) may add, 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) can 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 can 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 prediction samples can be controlled by a motion vector and are available to the motion-compensated prediction unit (453) in the form of a symbol (421) that can have, for example, X, Y, and reference picture components. Motion compensation can 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, and the like.
[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 can include in-loop filtering techniques that are controlled by parameters contained in the coded video sequence (also called the coded video bitstream) and made available to the loop filter unit (456) as symbols (421) from the parser (420), but can also be responsive to meta-information obtained during decoding of a coded picture or previous portion (in decoding order) of the coded video sequence, and can 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 the coded picture corresponding to the 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 standard, predetermined video compression technology, such as ITU-T Rec. H.265. An encoded video sequence may comply with the syntax specified by the video compression technology or standard being used, in the sense that the encoded video sequence complies with both the syntax of the video compression technology or standard and the profile documented in the video compression technology or standard. Specifically, a profile may select certain tools from all tools available in the video compression technology or standard as the only tools usable under that profile. Compliance also requires that the complexity of the encoded video sequence be within a range defined by the level of the video compression technology or standard. In some cases, the level may impose restrictions on the maximum picture size, maximum frame rate, maximum reconstruction sample rate (e.g., measured in megasamples per second), maximum reference picture size, etc. The restrictions set by the level may, in some cases, be further restricted 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 video encoder (303) in the example of FIG. 3.
[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, which 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 multiple individual pictures that, when viewed in sequence, impart motion. 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 will readily understand the relationship between pixels and samples. The following discussion 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 constraints 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, coupling is not depicted. Parameters set by the controller (550) may include rate control-related parameters (e.g., picture skip, quantizer, lambda value for rate-distortion optimization techniques), picture size, group of pictures (GOP) layout, maximum motion vector search range, etc. The controller (550) may be configured with 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 overly simplified 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) embedded in the video encoder (503). The decoder (533) reconstructs the symbols to create sample data in a manner similar to that of the (remote) decoder (because in the video compression techniques contemplated by 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). Because decoding of the symbol stream produces bit-exact results regardless of the location (local or remote) of the decoder, the contents of 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" the exact 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, 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 the corresponding encoder in substantially identical functional form. For this reason, the disclosed subject matter focuses on decoder operation. A description of the encoder techniques can be omitted, as they are the inverse of the decoder techniques that are described comprehensively. Only in certain areas is more detailed description necessary, and is 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 way, 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 coded video data of pictures that may be designated as reference pictures based on symbols created by the source coder (530). The operation of the coding engine (532) may advantageously be a lossy process. When the coded video data can be decoded by a video decoder (not shown in FIG. 5), the reconstructed video sequence may be a replica of the source video sequence, typically 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 for 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 suitable prediction references. 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 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 coded picture type to each coded 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 for various 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 predicted picture (P picture) may be one that can be coded and decoded using intra- or inter-prediction, which uses at most one motion vector and reference index to predict the sample values of each block.
[0057] Bidirectionally predicted pictures (B-pictures) may 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 may use more than two reference pictures and associated metadata for the reconstruction of a single block.
[0058] A source picture is generally spatially subdivided into multiple sample blocks (e.g., blocks of 4x4, 8x8, 4x8, or 16x16 samples each) and may be coded block by block. Blocks may be predictively coded with reference to other (already coded) blocks, as determined by the coding assignment applied to the block's respective picture. For example, blocks of an I-picture may be non-predictively coded or predictively coded with reference to already coded blocks of the same picture (spatial prediction or intra-prediction). Pixel blocks of a P-picture may be predictively coded via spatial prediction or via temporal prediction with reference to one previously coded reference picture. Blocks of a B-picture may be predictively coded via spatial prediction or via temporal prediction with reference to one or two previously coded reference pictures.
[0059] The video encoder (503) may perform encoding operations according to a predetermined video coding technique or standard, such as ITU-T Rec. H.265. In doing so, 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 in time sequence as multiple source pictures (video pictures). Intra-picture prediction (often abbreviated as intra-prediction) exploits spatial correlation within a given picture, while inter-picture prediction exploits correlation (temporal or otherwise) between pictures. In one example, a particular picture being encoded / decoded, called the current picture, is divided into blocks. When a block in the current picture is similar to a reference block in a previously encoded 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 before the decoding order of the current picture in the video (but may be in the past and future, respectively, in display order). 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 and second reference blocks.
[0063] Furthermore, merge mode techniques can be used for inter-picture prediction to improve coding efficiency.
[0064] According to some embodiments of the present disclosure, prediction, such as inter-picture prediction and intra-picture prediction, is performed block-by-block. 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 within a picture have the same size, such as 64x64 pixels, 32x32 pixels, or 16x16 pixels. Generally, 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 64x64 pixel CTU can be partitioned into one CU of 64x64 pixels, four CUs of 32x32 pixels, or 16 CUs of 16x16 pixels. In one example, each CU is analyzed to determine the CU's prediction type, such as inter-prediction type or intra-prediction type. The CU is then partitioned into one or more prediction units (PUs) according to temporal and / or spatial predictability. Generally, each PU includes a luma prediction block (PB) and two chroma PBs. In one embodiment, prediction operations in encoding (encoding / decoding) are performed in units of prediction blocks. Using a luma prediction block as an example of a prediction block, the prediction block includes a matrix of pixel values (e.g., luma values) of 8x8 pixels, 16x16 pixels, 8x16 pixels, 16x8 pixels, etc.
[0065] 6 shows a diagram of a video encoder (603) according to another embodiment of this 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 encode the processed block into an encoded picture that is part of the 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 8x8 samples. The video encoder (603) determines whether the processing block is best coded using intra-mode, inter-mode, or bi-predictive mode, e.g., 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. If the processing block is coded in inter-mode or bi-predictive mode, the video encoder (603) may use inter-prediction or bi-prediction techniques, respectively, to code the processing block into a coded picture. In certain video coding techniques, 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 Figure 6, the video encoder (603) includes an inter-encoder (630), an intra-encoder (622), a residual calculation unit (623), a switch (626), a residual encoder (624), a general controller (621), and an entropy encoder (625), which are coupled together as shown in Figure 6.
[0068] The inter-encoder (630) is configured to receive samples of a current block (e.g., a processing block), compare the block with one or more reference blocks in reference pictures (e.g., blocks in previous and subsequent pictures), generate inter-prediction information (e.g., inter-coding techniques, motion vectors, description of redundant information through 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), optionally compare the block with blocks already coded in the same picture, generate quantized coefficients after transformation, and optionally 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 the mode of the block and provides a control signal to the switch (626) based on the mode. For example, if the mode is intra mode, the general controller (621) controls the switch (626) to select the intra mode result used by the residual calculation unit (623) and controls the entropy encoder (625) to select intra prediction information to include in the bitstream. If the mode is inter mode, the general controller (621) controls the switch (626) to select the inter prediction result used by the residual calculation unit (623) and controls the entropy encoder (625) to select inter prediction information to include 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 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 to generate transform coefficients. The transform coefficients then undergo 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 inter-encoder (630). For example, the inter-encoder (630) may generate decoded blocks based on the decoded residual data and inter-prediction information, and the intra-encoder (622) may generate decoded blocks based on the decoded residual data and intra-prediction information. In some examples, the decoded blocks may be appropriately processed to generate decoded pictures, which may be buffered in a memory circuit (not shown) and used as reference pictures.
[0072] The entropy encoder (625) is configured to format a 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 an inter mode or a bi-prediction mode, 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 coded pictures that are part of a coded video sequence and decode the coded 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 Figure 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), which are coupled together as shown in Figure 7.
[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-prediction information or inter-prediction information) that can identify the mode in which the block is coded (e.g., intra-mode, inter-mode, the latter two being bi-prediction mode, merge sub-mode, or another sub-mode), certain samples or metadata used for prediction by the intra-decoder (772) or inter-decoder (780), respectively, residual information in the form of quantized transform coefficients, etc. In one example, if the prediction mode is an inter-prediction mode or a 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 be provided to the residual decoder (773).
[0076] The inter decoder (780) is configured to receive the inter prediction information and generate an inter prediction result based on the inter prediction information.
[0077] The intra decoder (772) is configured to receive intra prediction information and generate a prediction result based on the intra prediction information.
[0078] The residual decoder (773) is configured to perform inverse quantization to extract dequantized transform coefficients and process the dequantized 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) (data paths not shown may be low-level 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 appropriate 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 can be performed in the final stage of video encoding (or the first stage of video decoding) after a video signal has been reduced to a set of syntax elements. Entropy coding can be a lossless compression method that uses statistical properties to compress data so that the number of bits used to represent the data is logarithmically proportional to the probability of the data. For example, entropy coding can be performed across a set of syntax elements to convert bits representing the syntax elements (called bins) 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 can be determined for each bin in a set of bins based on the context associated with each bin. A binary arithmetic coding process can then be performed using the probability estimates to encode 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 shows 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 a binary syntax element 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 bins 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 that have been 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, referred to as a context model index or context index. Additionally, each context model can include a probability estimate or a parameter indicating the 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 the context index of 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 the 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 from 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) can 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 a transform block is first transformed from the spatial domain to the frequency domain, resulting in a block of transform coefficients. Quantization is then 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 in a bitstream. In one embodiment, the process of generating syntax elements from the transform coefficient levels can be performed as follows:
[0089] A block of transform coefficient levels may first be divided into sub-blocks, each having a size of, for example, 4x4 positions. These sub-blocks may be processed according to a predetermined scan order. Figure 9 shows an example of a sub-block scan order, called an anti-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. In the case of a sub-block whose transform coefficient levels are all 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 on 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 sub-block are shown in one dimension at the bottom of Figure 10. The positions (1010) are numbered from 0 to 15, reflecting their respective scan orders. During the 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 significance flag, denoted by sig_coeff_flag) that indicates whether the absolute transform coefficient level (denoted by absLevel) of each transform coefficient is 0 or greater than 0. (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 each transform coefficient. The parity flag is generated only if the absolute transform coefficient level of each 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) 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 each transform coefficient is greater than 4. The greater-than 2 flag is generated only if (absLevel-1)>>1 is greater than 0 for each 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 the 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) having a non-zero coefficient level indicating the sign of the respective transform coefficient level may be generated at each scan position (1010).
[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 encode different types of syntax elements. For example, in one embodiment, the significance flag, parity flag, greater-than-1 flag, and greater-than-2 flag may be encoded with a CABAC-based entropy encoder, such as the one described in the example of FIG. 8A. In contrast, the syntax elements generated during the third and fourth passes may be encoded with a CABAC-bypass entropy encoder (e.g., a binary arithmetic encoder with fixed probability estimates for the input bins).
[0096] Context modeling can be performed to determine a context model for a bin of some types of transform coefficient syntax elements. In one embodiment, the context model can 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 the current coefficient. The local template (1130) can cover a neighboring position or set of coefficients of the current coefficient (1120) within the coefficient block (1110). In the example of FIG. 11, the coefficient block (1110) has a size of 8x8 positions and contains coefficient levels at 64 positions. The coefficient block (1110) is divided into four sub-blocks, each having a size of 4x4 positions. In the example of FIG. 11, the local template (1130) is defined as a five-position template covering five coefficient levels to the lower right of the current coefficient (1120). When a reverse diagonal scan order is used for multiple passes over scan positions within the coefficient block (1110), neighboring positions within the local template (1130) are processed before the current coefficient (1120).
[0098] During context modeling, information about coefficient levels in the local template (1130) may be used to determine a context model. To this end, 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 levels may be determined according to the bins of the syntax elements sig_coeff_flag, par_level_flag, and rem_abs_gt 1_flag of each 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: 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 coordinates relative to the upper left corner of the coefficient block (1110), and absLevel1[x][y] represents the partially recovered absolute transform coefficient level at position (x, y).
[0100] In another example, the template magnitude is defined 1130 to be the difference, denoted 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, denoted 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 a transform coefficient or transform coefficient level.
[0102] In some embodiments, to take advantage of the correlation between transform coefficients, previously coded coefficients covered by the local template shown in Figure 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] represent the partially reconstructed absolute level of the coefficient at position (x, y) after the first pass, d represent the diagonal position (d=x+y) of the current coefficient, and sumAbs1 represent the sum of the partially reconstructed 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 positions of coefficients or coefficient levels within a coefficient block (1210). In one embodiment, the diagonal positions of a scan position (x, y) are defined according to: Equation (3): d = x + y, where d represents the diagonal position, and x and y are the coordinates of each position. 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 by d<=3, while the high-frequency region (1230) is defined by d>=11, as shown in Figure 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)) Equation (6): ctxSig = base + offset
[0105] For a chroma component, the context model index is determined according to: 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, the complexity of hardware and software also increases. Therefore, it is desirable to reduce the number of context models without sacrificing coding efficiency. In particular, the standardized context modeling method of VVC Draft 5 uses more than 21% of the 424 context models, so it is desirable to reduce the number of context models for coding the significance of transform coefficients.
[0110] The embodiments of the present disclosure may be used separately or combined in any order. Furthermore, 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, the 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 for 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
[0112] , , Y , , , , , , , and d 1Y are diagonal position thresholds for the luma region. In one exemplary embodiment, d 0Y is 2 and d 1Y are 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, the embodiment of the function f(x) is defined as follows. f(x)=x-(x>>2) (vi) When N is 4, the 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 in some embodiments as follows: 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)) Equation (12): ctxSig = base + offset
[0113] For a chroma component, the context model index is determined according to: Equation (13): offset = min(f(sumAbs 1), N-1) Equation (14): Base = 2*N*max(0, state-1) + (d <d0 C ?N:0) Equation (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 a non-negative integer x can be defined as follows: Formula (16):
number
number
[0116] According to some embodiments, the context region depends on the diagonal position d, so the number of context models per region depends on the diagonal position d, which can further reduce 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 a non-negative integer x. Example values of N1, N2, and N3 can 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 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 for 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, the 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) Equation (23): ctxSig = base + offset
[0119] For the chroma components, the context model index is determined according to: Equation (24): offset = min(f(sumAbs 1), N-1) Equation (25): Base = 2*N*max(0, state-1) + (d <d 0C ?N:0) Equation (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 a coded 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 the 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 the sum of the determined offset value and a base value. As an example, the context model index may be determined according to the process shown in either FIG. 14 or FIG. 15, or an alternative embodiment 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 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 transform coefficients 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, the output of a monotonically non-decreasing function applied to the sum (x) of the group of partially reconstructed transform coefficients and the 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 upper-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 plurality of context models for at least one syntax of the current transform coefficient based on the determined context model index.
[0124] The techniques described above may be implemented as computer software using computer-readable instructions and physically stored on one or more computer-readable media. For example, Figure 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, smartphones, gaming devices, Internet of Things devices, and the like.
[0127] 18 for computer system (1800) are exemplary in nature and are not intended to suggest any limitation on the scope of use or functionality of the computer software implementing 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 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 (e.g., keystrokes, swipes, data glove movements), audio input (e.g., voice, clapping), visual input (e.g., gestures), or 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 audio (e.g., speech, music, ambient sounds), images (e.g., scanned images obtained from a still camera, photographic images), and video (e.g., two-dimensional video, three-dimensional video including stereoscopic video).
[0129] The input human interface devices may include one or more of a keyboard (1801), a mouse (1802), a trackpad (1803), a touchscreen (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 via a touchscreen (1810), data gloves (not shown), or joystick (1805), although haptic feedback devices that do not function as input devices may also be included), 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, and OLED screens, each with or without touchscreen input capability, each with or without haptic feedback capability, some of which may be capable of two-dimensional visual output or three-dimensional or higher 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 tape or 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. Networks may be, for example, wireless, wired, or optical. Networks may further be local, wide-area, metropolitan, vehicular, and industrial, real-time, delay-tolerant, and the like. Examples of networks include local area networks such as Ethernet and wireless LAN; cellular networks including global systems for GSM, 3G, 4G, 5G, LTE, and the like; television wired or wireless wide-area digital networks including cable television, satellite television, and terrestrial broadcast television; and vehicular and industrial networks including CANBus. Certain networks typically require an external network interface adapter attached to a particular general data port or peripheral bus (1849) (e.g., a USB port on the computer system (1800)); 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). Using any of these networks, the computer system (1800) can communicate with other entities. Such communication 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 the 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 arrays (FPGAs) (1843), hardware accelerators for specific tasks (1844), etc. These devices may connect via a system bus (1848) along with read-only memory (ROM) (1845), random access memory (1846), and internal mass storage devices (1847) such as non-user-accessible internal hard drives, SSDs, etc. 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, etc. Peripheral devices may connect directly to the core's system bus (1848) or via a peripheral bus (1849). Peripheral bus architectures include PCI, USB, etc.
[0136] The CPU (1841), GPU (1842), FPGA (1843), and accelerator (1844) can execute specific instructions that, in combination, can constitute the aforementioned computer code. That 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 enabled 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 may be those specially designed and constructed for the purposes of the present disclosure, or they may be of the kind well known and available to those skilled in the computer software arts.
[0138] By way of example, and not 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 may be the user-accessible mass storage devices introduced above, as well as media associated with specific storage of the core (1840) that is non-transitory in nature, such as the core's internal mass storage device (1847) or ROM (1845). Software implementing various embodiments of the present disclosure may be stored on such devices and executed by the core (1840). The computer-readable media may include one or more memory devices or chips, depending on particular needs. The software may cause the core (1840), and in particular the processor (including a CPU, GPU, FPGA, etc.) therein, to perform particular processes or particular portions of particular processes described herein, including defining data structures stored in RAM (1846) and modifying such data structures in accordance with the software-defined processes. Additionally or alternatively, a computer system may provide functionality as a result of logic hardwired into or embodied in circuitry (e.g., accelerator 1844) that can operate in place of or together with software to perform particular processes or portions of particular processes described herein. References to software can include logic, and vice versa, as appropriate. References to computer-readable media can encompass circuitry (such as an integrated circuit (IC)) 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 fall within the scope of this 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 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 feature (2), 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 feature (3), wherein the current coefficient is located in the luma domain, and the base value is based on a comparison of the distance of the current coefficient from an upper 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 feature (3), wherein the current coefficient is located in a chroma domain, and the base value is based on a comparison of the distance of the current coefficient from an upper left corner of the transform block to a first diagonal position threshold.
[0146] (7) The method of any one of features (1) to (6), wherein the monotonically non-decreasing function is defined as x-(x>>2).
[0147] (8) The method of 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 determining the context model index is further based on a comparison of the distance of the current coefficient from the upper 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 determining the context model index is further based on a comparison of the distance of the current coefficient from the upper left corner of the transform block and the 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 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 the 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 the distance of the current coefficient from the upper 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 device 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 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. [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 Pictures 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 Symbol 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 Interdecoder 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 sub-block 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 touchscreen 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 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+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.
Citation Information
Patent Citations
Coding of Coefficient Levels in Video Coding
JP2018529273A
Method and apparatus for video encoding and decoding based on context switching
US20200322610A1