Escape coding for coefficient levels

Abstract

As a part that bypass decodes syntax elements for a set of coefficients in response to reaching a maximum number of normally coded bins, the video decoder is configured to receive a prefix value for a transform coefficient; decode the prefix value using Golomb-Rice coding; receive a suffix value for a transform coefficient in response to the length of the prefix value being equal to a threshold value; decode the suffix value using exponential Golomb coding; and determine a level value for the transform coefficient based on the decoded prefix value and the decoded suffix value.

Description

Technology Field

[0001] The present application claims priority to U.S. application No. 16 / 732,008 filed on December 31, 2019, which claims interest to U.S. provisional application No. 62 / 787,707 filed on January 2, 2019, and the entire contents of said applications are incorporated by reference therein.

[0002] The present disclosure relates to video encoding and video decoding. Background Technology

[0003] Digital video capabilities may be included in a wide range of devices, including digital televisions, digital direct broadcast systems, wireless broadcast systems, personal digital assistants (PDAs), laptop or desktop computers, tablet computers, e-book readers, digital cameras, digital recording devices, digital media players, video gaming devices, video game consoles, cellular or satellite radio phones, so-called "smartphones," video conferencing devices, video streaming devices, etc. Digital video devices implement video coding techniques such as those described in standards defined by MPEG-2, MPEG-4, ITU-T H.263, ITU-T H.264 / MPEG-4, Part 10, Advanced Video Coding (AVC), High Efficiency Video Coding (HEVC) standards, ITU-T H.265 / HEVC (High Efficiency Video Coding), and extensions of such standards. Video devices can transmit, receive, encode, decode, and / or store digital video information more efficiently by implementing such video coding techniques.

[0004] Video coding techniques include spatial (intra-picture) prediction and / or temporal (inter-picture) prediction to reduce or eliminate redundancy inherent to video sequences. For block-based video coding, a video slice (e.g., a video picture or a part of a video picture) may be partitioned into video blocks, which may also be referred to as coding tree units (CTUs), coding units (CUs), and / or coding nodes. Video blocks in an intra-coded (I) slice of a picture are encoded using spatial prediction for reference samples within neighboring blocks in the same picture. Video blocks in an inter-coded (P or B) slice of a picture may use spatial prediction for reference samples within neighboring blocks in the same picture, or temporal prediction for reference samples in other reference pictures. Pictures can be referred to as frames, and reference pictures can be referred to as reference frames.

[0005] Video coding (e.g., video encoding and / or video decoding) typically involves predicting a video data block from a video data block already coded in the same picture (e.g., intra-predict) or from a video data block already coded in a different picture (e.g., inter-predict). In some cases, the video encoder also calculates residual data by comparing the predicted block with the original block. Thus, residual data represents the difference between the predicted block and the original video data block. To reduce the number of bits required to signal residual data, the video encoder converts the residual data into transform factors, quantizes the transform factors, and signals the transformed and quantized factors in the encoded bitstream. The compression achieved by the transform and quantization processes may be lost, which means that the transform and quantization processes may introduce distortion into the decoded video data. The present disclosure describes techniques related to transform factor coding and, more specifically, techniques regarding the use of a combination of Golomb-Rice and exponential Golomb coding. The techniques of the present disclosure can improve the coding efficiency of transformation coefficients by reducing, on average, the number of bits required to signal the transformation coefficients. Additionally, the techniques of the present disclosure can limit worst-case coding scenarios associated with signaling the transformation coefficients.

[0006] According to an example of the present disclosure, a method for decoding video data comprises the step of context-decoding syntax elements for a first set of transform coefficients of a group of transform coefficients until reaching a maximum number of normally coded bins — the context-decoded syntax elements include one or more importance flags, one or more parity level flags, and one or more first flags, each of the one or more importance flags indicates whether the absolute level for the transform coefficient is equal to 0, each of the one or more parity level flags indicates whether the transform coefficient has an even or odd absolute level, and each of the one or more first flags indicates whether the transform coefficient has an absolute level greater than 2 —; the step of bypass-decoding additional syntax elements for a second set of coefficients in response to reaching a maximum number of normally coded bins — the step of bypass-decoding additional syntax elements comprises receiving a prefix value for the transform coefficient; The method comprises: decoding a prefix value using Golomb-Rice coding; receiving a suffix value for a transformation coefficient in response to the length of the prefix value being equal to a threshold value; and decoding the suffix value using exponential Golomb coding; determining values ​​for a first set of coefficients of a transformation unit based on context-decoded syntax elements; and determining values ​​for a second set of coefficients of a transformation unit based on additional syntax elements, wherein the step of determining values ​​for a second set of coefficients of a transformation unit based on additional syntax elements includes determining a level value for a transformation coefficient based on the decoded prefix value and the decoded suffix value.

[0007] According to another example of the present disclosure, a device for decoding video data comprises a memory configured to store video data and one or more processors implemented as a circuit, wherein the one or more processors context-decode syntax elements for a first set of coefficients of a group of transform coefficients until a maximum number of normally coded bins are reached — the context-decoded syntax elements comprise one or more importance flags, one or more parity level flags, and one or more first flags, wherein each of the one or more importance flags indicates whether the absolute level for the transform coefficient is equal to 0, each of the one or more parity level flags indicates whether the transform coefficient has an even or odd absolute level, and each of the one or more first flags indicates whether the transform coefficient has an absolute level greater than 2 —; In response to reaching a maximum number of normally coded bins, additional syntax elements for a second set of coefficients are bypass decoded — to bypass decoded additional syntax elements, one or more processors are configured to receive a prefix value for a transformation coefficient; decode the prefix value using Golomb-Rice coding; receive a suffix value for a transformation coefficient in response to the length of the prefix value being equal to a threshold value; and decode the suffix value using exponential Golomb coding —; determine values ​​for a first set of coefficients of a transformation unit based on context-decoded syntax elements; and determine values ​​for a second set of coefficients of a transformation unit based on additional syntax elements, and to determine values ​​for a second set of coefficients of a transformation unit based on additional syntax elements, one or more processors are configured to determine level values ​​for a transformation coefficient based on the decoded prefix value and the decoded suffix value.

[0008] According to another example of the present disclosure, a computer-readable storage medium for storing instructions, wherein the instructions, when executed by one or more processors, cause one or more processors to context-decode syntax elements for a first set of conversion factors of a group of conversion factors until they reach a maximum number of normally coded bins — the context-decoded syntax elements comprise one or more importance flags, one or more parity level flags, and one or more first flags, each of the one or more importance flags indicates whether the absolute level for the conversion factor is equal to 0, each of the one or more parity level flags indicates whether the conversion factor has an even or odd absolute level, and each of the one or more first flags indicates whether the conversion factor has an absolute level greater than 2 —; In response to reaching a maximum number of normally coded bins, additional syntax elements for a second set of coefficients are bypass decoded — to bypass decode additional syntax elements, instructions cause one or more processors to receive a prefix value for a conversion coefficient; to decode the prefix value using Golomb-Rice coding; in response to the length of the prefix value being equal to a threshold value, to receive a suffix value for a conversion coefficient; and to decode the suffix value using exponential Golomb coding —; to determine values ​​for a first set of coefficients of a conversion unit based on context-decoded syntax elements; and to determine values ​​for a second set of coefficients of a conversion unit based on additional syntax elements, and determining values ​​for a second set of coefficients of a conversion unit based on additional syntax elements includes determining level values ​​for a conversion coefficient based on the decoded prefix value and the decoded suffix value.

[0009] According to another example of the present disclosure, an apparatus for decoding video data comprises: means for context-decoding syntax elements for a first set of transform coefficients of a group of transform coefficients until reaching a maximum number of normally coded bins — the context-decoded syntax elements comprise one or more importance flags, one or more parity level flags, and one or more first flags, each of the one or more importance flags indicates whether the absolute level for the transform coefficient is equal to 0, each of the one or more parity level flags indicates whether the transform coefficient has an even or odd absolute level, and each of the one or more first flags indicates whether the transform coefficient has an absolute level greater than 2 —; means for bypass-decoding additional syntax elements for a second set of coefficients in response to reaching a maximum number of normally coded bins — the means for bypass-decoding additional syntax elements comprises: means for receiving a prefix value for the transform coefficient; Means for decoding a prefix value using Golomb-Rice coding; means for receiving a suffix value for a transformation coefficient in response to the length of the prefix value being equal to a threshold value; and means for decoding a suffix value using exponential Golomb coding; means for determining values ​​for a first set of coefficients of a transformation unit based on context-decoded syntax elements; and means for determining values ​​for a second set of coefficients of a transformation unit based on additional syntax elements, wherein determining values ​​for a second set of coefficients of a transformation unit based on additional syntax elements includes determining a level value for a transformation coefficient based on the decoded prefix value and the decoded suffix value.

[0010] According to another example of the present disclosure, a method for encoding video data comprises: determining values ​​for coefficients of a group of transform coefficients; context encoding syntax elements for a first set of coefficients of a group of transform coefficients until a maximum number of normally coded bins is reached — the context encoded syntax elements include one or more importance flags, one or more parity level flags, and one or more first flags, each of the one or more importance flags indicates whether the absolute level for the transform coefficient is equal to 0, each of the one or more parity level flags indicates whether the transform coefficient has an even or odd absolute level, and each of the one or more first flags indicates whether the transform coefficient has an absolute level greater than 2 —; and bypass encoding additional syntax elements for a second set of coefficients of a group of transform coefficients in response to reaching a maximum number of normally coded bins, wherein the step of bypass encoding additional syntax elements includes determining a level value for the transform coefficient of the second set of coefficients; The method includes the step of encoding a prefix value for a transformation factor using Golomb-Rice coding in response to the level value being greater than a threshold; and the step of encoding a suffix value using exponential Golomb coding in response to the level value being greater than a threshold.

[0011] According to another example of the present disclosure, a device for encoding video data comprises a memory configured to store video data and one or more processors implemented as a circuit, wherein the one or more processors determine values ​​for coefficients of a group of transform coefficients; and context-encode syntax elements for a first set of coefficients of a group of transform coefficients until a maximum number of normally coded bins are reached — the context-encoded syntax elements comprise one or more importance flags, one or more parity level flags, and one or more first flags, wherein each of the one or more importance flags indicates whether the absolute level for the transform coefficient is equal to 0, each of the one or more parity level flags indicates whether the transform coefficient has an even or odd absolute level, and each of the one or more first flags indicates whether the transform coefficient has an absolute level greater than 2 —; And is configured to bypass-encode additional syntax elements for a second set of coefficients of a group of transformation coefficients in response to reaching a maximum number of normally coded bins, wherein bypass-encoding additional syntax elements comprises determining a level value for the transformation coefficient of the second set of coefficients; encoding a prefix value for the transformation coefficient using Golomb-Rice coding in response to the level value being greater than a threshold value; and encoding a suffix value using exponential Golomb coding in response to the level value being greater than a threshold value.

[0012] According to another example of the present disclosure, a computer-readable storage medium for storing instructions, wherein the instructions, when executed by one or more processors, cause one or more processors to determine values ​​for coefficients of a group of conversion coefficients; and context-encode syntax elements for a first set of coefficients of a group of conversion coefficients until a maximum number of normally coded bins are reached — the context-encoded syntax elements include one or more importance flags, one or more parity level flags, and one or more first flags, each of the one or more importance flags indicates whether the absolute level for the conversion coefficient is equal to 0, each of the one or more parity level flags indicates whether the conversion coefficient has an even or odd absolute level, and each of the one or more first flags indicates whether the conversion coefficient has an absolute level greater than 2 —; And in response to reaching a maximum number of normally coded bins, additional syntax elements for a second set of coefficients of a group of transformation coefficients are bypass encoded, and to bypass encoded additional syntax elements, instructions cause one or more processors to determine a level value for the transformation coefficients of the second set of coefficients; in response to the level value being greater than a threshold, to encode a prefix value for the transformation coefficients using Golomb-Rice coding; and in response to the level value being greater than a threshold, to encode a suffix value using exponential Golomb coding.

[0013] According to another example of the present disclosure, an apparatus for encoding video data comprises: means for determining values ​​for coefficients of a group of transform coefficients; means for context-encoding syntax elements for a first set of coefficients of a group of transform coefficients until a maximum number of normally coded bins is reached — the context-encoded syntax elements include one or more importance flags, one or more parity level flags, and one or more first flags, each of the one or more importance flags indicates whether the absolute level for the transform coefficient is equal to 0, each of the one or more parity level flags indicates whether the transform coefficient has an even or odd absolute level, and each of the one or more first flags indicates whether the transform coefficient has an absolute level greater than 2 —; and means for bypass-encoding additional syntax elements for a second set of coefficients of a group of transform coefficients in response to reaching a maximum number of normally coded bins, wherein the means for bypass-encoding additional syntax elements comprises: means for determining a level value for the transform coefficient of the second set of coefficients; Means for encoding a prefix value for a transformation factor using Golomb-Rice coding in response to a level value being greater than a threshold; and means for encoding a suffix value using exponential Golomb coding in response to a level value being greater than a threshold.

[0014] Details of one or more examples are described in the description below and in the attached drawings. Other features, purposes, and advantages will become apparent from the description, drawings, and claims. Brief explanation of the drawing

[0015] FIG. 1 is a block diagram illustrating an exemplary video encoding and decoding system capable of performing the techniques of the present disclosure.

[0016] Figures 2a and 2b are conceptual diagrams illustrating an exemplary quadtree binary tree (QTBT) structure and a corresponding coding tree unit (CTU).

[0017] Figure 3 illustrates an exemplary sequence of syntax elements representing absolute levels (absLevel) in a coding group (CG).

[0018] Figure 4 illustrates an example of a template used to select probabilistic models.

[0019] FIG. 5 is a block diagram illustrating an exemplary video encoder capable of performing the techniques of the present disclosure.

[0020] FIG. 6 is a block diagram illustrating an exemplary video decoder capable of performing the techniques of the present disclosure.

[0021] Figures 7a and 7b are conceptual diagrams illustrating the range update process in binary arithmetic coding.

[0022] Figure 8 is a conceptual diagram illustrating the output process in binary arithmetic coding.

[0023] Figure 9 is a block diagram illustrating a CABAC (context adaptive binary arithmetic coding) coder in a video encoder.

[0024] Figure 10 is a block diagram illustrating a CABAC coder in a video decoder.

[0025] Figure 11 is a flowchart illustrating the exemplary operation of a video encoder.

[0026] Figure 12 is a flowchart illustrating the exemplary operation of a video decoder.

[0027] FIG. 13 is a flowchart illustrating the exemplary operation of a video encoder for encoding a current block of video data.

[0028] FIG. 14 is a flowchart illustrating an exemplary operation of a video encoder for bypass encoding additional syntax elements for a second set of coefficients of the transform coefficient group of FIG. 13.

[0029] FIG. 15 is a flowchart illustrating an exemplary operation of a video decoder for decoding a current block of video data.

[0030] FIG. 16 is a flowchart illustrating an exemplary operation of a video decoder for bypass decoding additional syntax elements for a second set of coefficients of the coefficient group of FIG. 15. Specific details for implementing the invention

[0031] Video coding (e.g., video encoding and / or video decoding) typically involves predicting a video data block from a video data block already coded in the same picture (e.g., intra-prediction) or from a video data block already coded in a different picture (e.g., inter-prediction). In some cases, the video encoder also calculates residual data by comparing the predicted block with the original block. Thus, residual data represents the difference between the predicted block and the original video data block. To reduce the number of bits required to signal the residual data, the video encoder transforms and quantizes the residual data and signals the transformed and quantized residual data in the encoded bitstream. The compression achieved by the transformation and quantization processes may be lost, which means that the transformation and quantization processes can introduce distortion into the decoded video data.

[0032] A video decoder decodes residual data and adds it to a prediction block to generate a reconstructed video block that matches the original video block more closely than the prediction block alone. Due to losses introduced by the transformation and quantization of the residual data, the reconstructed block may have distortions or artifacts. One common type of artifact or distortion is referred to as blockiness, where the boundaries of the blocks used to code the video data may be visible.

[0033] To further improve the quality of the decoded video, the video decoder may perform one or more filtering operations on the restored video blocks. Examples of these filtering operations include deblocking filtering, sample adaptive offset (SAO) filtering, and adaptive loop filtering (ALF). Parameters for these filtering operations may be determined by the video encoder and explicitly signaled in the encoded video bitstream, or they may be implicitly determined by the video decoder without requiring parameters to be explicitly signaled in the encoded video bitstream.

[0034] As introduced above, the video encoder transforms residual data to generate transform coefficients. These transform coefficients may be further quantized. In this disclosure, the terms transform coefficient or coefficient may refer to a quantized transform coefficient or a non-quantized transform coefficient. This disclosure describes techniques for signaling transform coefficients, e.g., the values ​​of quantized transform coefficients, from a video encoder to a video decoder. Such techniques include techniques for an entropy decoding process that transforms a binary representation of bits into a series of non-binary value quantized transform coefficients. More specifically, this disclosure describes techniques for coding escape codes that represent a portion of the coefficient level that is not context-coded, which is instead coded as a Golomb-Rice / exponential Golomb combination. A corresponding entropy encoding process, which is generally the inverse process of entropy decoding, is also described in this disclosure.

[0035] The techniques of the present disclosure may be implemented together with techniques of existing video codecs such as HEVC (High Efficiency Video Coding) or may be included as part of future video codecs such as the VVC (Versatile Video Coding) standard currently under development.

[0036] FIG. 1 is a block diagram illustrating an exemplary video encoding and decoding system (100) capable of performing the techniques of the present disclosure. The techniques of the present disclosure generally relate to coding (encoding and / or decoding) video data. Generally, video data includes any data for processing video. Accordingly, video data may include video metadata such as raw, uncoded video, encoded video, decoded (e.g., restored) video, and signaling data.

[0037] As illustrated in FIG. 1, the system (100) includes, in this example, a source device (102) that provides encoded video data to be decoded and displayed by a destination device (116). In particular, the source device (102) provides the video data to the destination device (116) via a computer-readable medium (110). The source device (102) and the destination device (116) may be any of a wide range of devices including desktop computers, notebook (i.e., laptop) computers, tablet computers, set-top boxes, telephone handsets such as smartphones, televisions, cameras, display devices, digital media players, video gaming consoles, video streaming devices, etc. In some cases, the source device (102) and the destination device (116) may be equipped for wireless communication and may accordingly be referred to as wireless communication devices.

[0038] In the example of FIG. 1, the source device (102) includes a video source (104), memory (106), a video encoder (200), and an output interface (108). The destination device (116) includes an input interface (122), a video decoder (300), memory (120), and a display device (118). According to the present disclosure, the video encoder (200) of the source device (102) and the video decoder (300) of the destination device (116) may be configured to apply the coefficient coding techniques described in the present disclosure. Thus, the source device (102) represents an example of a video encoding device, while the destination device (116) represents an example of a video decoding device. In other examples, the source device and the destination device may include other components or arrangements. For example, the source device (102) may receive video data from an external video source, such as an external camera. Likewise, the destination device (116) may interface with an external display device rather than including an integrated display device.

[0039] The system (100) as illustrated in FIG. 1 is merely one example. In general, any digital video encoding and / or decoding device may perform the counting coding techniques described herein. The source device (102) and the destination device (116) are merely examples of such coding devices in which the source device (102) generates coded video data for transmission to the destination device (116). The present disclosure refers to a “coding” device as a device that performs the coding (encoding and / or decoding) of data. Accordingly, the video encoder (200) and the video decoder (300) each represent examples of coding devices, in particular, a video encoder and a video decoder. In some examples, the source device (102) and the destination device (116) may operate in a substantially symmetric manner such that the source device (102) and the destination device (116) each include video encoding and decoding components. Accordingly, the system (100) can support unidirectional or bidirectional video transmission between a video source device (102) and a destination device (116) for, for example, video streaming, video playback, video broadcasting, or video telephony.

[0040] Generally, the video source (104) represents a source of video data (i.e., raw, unencoded video data) and provides a sequential series of pictures of the video data (also referred to as “frames”) to the video encoder (200), which encodes the data for the pictures. The video source (104) of the source device (102) may include a video capture device such as a video camera, a video archive containing previously captured raw video, and / or a video supply interface for receiving video from a video content provider. As an additional alternative, the video source (104) may generate computer graphics-based data as a source video, or as a combination of live video, archived video, and computer-generated video. In each case, the video encoder (200) encodes the captured, pre-captured, or computer-generated video data. The video encoder (200) can rearrange the pictures from the received order (sometimes referred to as the “display order”) into a coding order for coding. The video encoder (200) can generate a bitstream containing encoded video data. Then, the source device (102) can output the encoded video data to a computer-readable medium (110) through an output interface (108) for reception and / or retrieval, for example, by the input interface (122) of the destination device (116).

[0041] The memory (106) of the source device (102) and the memory (120) of the destination device (116) represent general-purpose memories. In some examples, the memories (106, 120) may store raw video data, e.g., raw video from a video source (104) and raw decoded video data from a video decoder (300). Additionally or alternatively, the memories (106, 120) may store software instructions executable by, e.g., a video encoder (200) and a video decoder (300), respectively. Although the memory (106) and memory (120) are depicted separately from the video encoder (200) and video decoder (300) in this example, it should be understood that the video encoder (200) and video decoder (300) may also include internal memories for functionally similar or equivalent purposes. Additionally, the memories (106, 120) can store encoded video data, such as output from the video encoder (200) and input to the video decoder (300). In some examples, parts of the memories (106, 120) may be allocated as one or more video buffers to store, for example, raw, decoded, and / or encoded video data.

[0042] The computer-readable medium (110) may represent any type of medium or device capable of transmitting encoded video data from a source device (102) to a destination device (116). In one example, the computer-readable medium (110) represents a communication medium that enables the source device (102) to transmit the encoded video data directly to the destination device (116) in real time, for example, via a radio frequency network or a computer-based network. An output interface (108) may modulate a transmission signal containing the encoded video data, and an input interface (122) may demodulate a received transmission signal according to a communication standard, such as a wireless communication protocol. The communication medium may include any wireless or wired communication medium, such as a radio frequency (RF) spectrum or one or more physical transmission lines. The communication medium may form part of a packet-based network, such as a local area network, a wide area network, or a global network such as the Internet. The communication medium may include routers, switches, base stations, or any other equipment that may be useful for enabling communication from a source device (102) to a destination device (116).

[0043] In some examples, the source device (102) may output encoded data from the output interface (108) to the storage device (112). Similarly, the destination device (116) may access the encoded data from the storage device (112) through the input interface (122). The storage device (112) may include any of various distributed or locally accessed data storage media, such as a hard drive, Blu-ray discs, DVDs, CD-ROMs, flash memory, volatile or non-volatile memory, or any other suitable digital storage media for storing encoded video data.

[0044] In some examples, the source device (102) may output encoded video data to a file server (114) or other intermediate storage device capable of storing the encoded video generated by the source device (102). The destination device (116) may access the stored video data from the file server (114) via streaming or download. The file server (114) may be any type of server device capable of storing the encoded video data and transmitting the encoded video data to the destination device (116). The file server (114) may represent a web server (e.g., for a website), an FTP (File Transfer Protocol) server, a content delivery network device, or a NAS (network attached storage) device. The destination device (116) may access the encoded video data from the file server (114) via any standard data connection, including an internet connection. This may include a wireless channel (e.g., Wi-Fi connection), a wired connection (e.g., a digital subscriber line (DSL), a cable modem, etc.), or a combination of both, suitable for accessing encoded video data stored on the file server (114). The file server (114) and the input interface (122) may be configured to operate according to a streaming transmission protocol, a download transmission protocol, or a combination thereof.

[0045] The output interface (108) and input interface (122) may represent wireless transmitters / receivers, modems, wired networking components (e.g., Ethernet cards), wireless communication components operating according to any of the various IEEE 802.11 standards, or other physical components. In examples where the output interface (108) and input interface (122) include wireless components, the output interface (108) and input interface (122) may be configured to transmit data, such as encoded video data, according to cellular communication standards such as 4G, 4G-LTE (Long-Term Evolution), LTE Advanced, 5G, etc. In some examples where the output interface (108) includes a wireless transmitter, the output interface (108) and input interface (122) may be configured to transmit data, such as encoded video data, according to other wireless standards such as IEEE 802.11 standards, IEEE 802.15 standards (e.g., ZigBee™), Bluetooth™ standards, etc. In some examples, the source device (102) and / or the destination device (116) may include individual system-on-a-chip (SoC) devices. For example, the source device (102) may include an SoC device for performing functions attributed to a video encoder (200) and / or an output interface (108), and the destination device (116) may include an SoC device for performing functions attributed to a video decoder (300) and / or an input interface (122).

[0046] The techniques of the present disclosure may be applied to video coding in support of any of various multimedia applications, such as over-the-air television broadcasts, cable television transmissions, satellite television transmissions, internet streaming video transmissions such as DASH (dynamic adaptive streaming over HTTP), digital video encoded on a data storage medium, decoding of digital video stored on a data storage medium, or other applications.

[0047] The input interface (122) of the destination device (116) receives an encoded video bitstream from a computer-readable medium (110) (e.g., a communication medium, a storage device (112), a file server (114), etc.). The encoded video bitstream may include signaling information defined by a video encoder (200), such as syntax elements having values ​​describing the characteristics and / or processing of video blocks or other coded units (e.g., slices, pictures, groups of pictures, sequences, etc.) (which is also used by a video decoder (300)). A display device (118) displays decoded pictures of the decoded video data to a user. The display device (118) may display any of various display devices, such as a cathode ray tube (CRT), a liquid crystal display (LCD), a plasma display, an organic light emitting diode (OLED) display, or another type of display device.

[0048] Although not illustrated in FIG. 1, in some examples, the video encoder (200) and the video decoder (300) may each be integrated with an audio encoder and / or an audio decoder and may include suitable MUX-DEMUX units or other hardware and / or software to handle multiplexed streams containing both audio and video in a common data stream. Where applicable, the MUX-DEMUX units may comply with the ITU H.223 multiplexer protocol or other protocols such as UDP (user datagram protocol).

[0049] The video encoder (200) and the video decoder (300) may each be implemented as any of various suitable encoder and / or decoder networks, such as one or more microprocessors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field programmable gate arrays (FPGAs), discrete logic, software, hardware, firmware, or any combination thereof. When the techniques are partially implemented in software, the device may store instructions for the software in a suitable non-transient computer-readable medium and execute instructions in hardware using one or more processors to perform the techniques of the present disclosure. Each of the video encoder (200) and the video decoder (300) may be included in one or more encoders or decoders, and either of the encoders or decoders may be integrated as part of an encoder / decoder (CODEC) combined within the individual device. A device including a video encoder (200) and / or a video decoder (300) may include an integrated circuit, a microprocessor, and / or a wireless communication device such as a cellular phone.

[0050] The video encoder (200) and video decoder (300) may operate according to a video coding standard, such as ITU-T H.265 (also referred to as HEVC (High Efficiency Video Coding)), or extensions thereof, such as multi-view and / or scalable video coding extensions. Alternatively, the video encoder (200) and video decoder (300) may operate according to other proprietary or industry standards, such as JEM (Joint Exploration Test Model) or ITU-T H.266 (also referred to as VVC (Versatile Video Coding)). A recent draft of the VVC standard is Bross, et al. "Versatile Video Coding (Draft 6)," Joint Video Experts Team (JVET) of ITU-T SG 16 WP 3 and ISO / IEC JTC 1 / SC 29 / WG 11, 15 th Meeting: Gothenburg, SE, 3-12 July 2019, described in JVET-O2001-vE (hereinafter "VVC Draft 6"). However, the techniques of the present disclosure are not limited to any specific coding standard.

[0051] Generally, the video encoder (200) and video decoder (300) can perform block-based coding of pictures. The term “block” generally refers to a structure containing data to be processed (e.g., encoding, decoding, or other used in the encoding and / or decoding process). For example, a block may contain a two-dimensional matrix of samples of luminance and / or chrominance data. Generally, the video encoder (200) and video decoder (300) can code video data expressed in a YUV (e.g., Y, Cb, Cr) format. That is, the video encoder (200) and video decoder (300) can code luminance and chrominance components rather than RGB (red, green, and blue) data for samples of a picture, wherein the chrominance components may include both red hue and blue hue chrominance components. In some examples, the video encoder (200) converts the received RGB-formatted data into a YUV representation prior to encoding, and the video decoder (300) converts the YUV representation into an RGB format. Alternatively, pre-processing and post-processing units (not shown) may perform these conversions.

[0052] The present disclosure may generally refer to the coding of pictures (e.g., encoding and decoding) for including a process of encoding or decoding data of the pictures. Similarly, the present disclosure may refer to the coding of blocks of pictures for including a process of encoding or decoding data of the blocks, e.g., predictive and / or residual coding. An encoded video bitstream generally includes a series of values ​​for syntax elements representing coding decisions (e.g., coding modes) and the partitioning of pictures into blocks. Accordingly, references to the coding of a picture or block should generally be understood as coding values ​​for the syntax elements forming the picture or block.

[0053] HEVC defines various blocks including coding units (CUs), prediction units (PUs), and transform units (TUs). According to HEVC, a video coder (e.g., a video encoder (200)) partitions coding tree units (CTUs) into CUs according to a quadtree structure. That is, the video coder partitions the CTUs and CUs into four identical, non-overlapping squares, and each quadtree node has zero or four child nodes. Nodes without child nodes may be referred to as "leaf nodes," and the CUs of such leaf nodes may contain one or more PUs and / or one or more TUs. The video coder may further partition the PUs and TUs. For example, in HEVC, a residual quadtree (RQT) represents the partitioning of TUs. In HEVC, PUs represent inter-predicted data, while TUs represent residual data. Intra-predicted CUs contain intra-predicted information such as intra-mode prediction.

[0054] As another example, the video encoder (200) and video decoder (300) may be configured to operate according to JEM or VVC. According to JEM or VVC, the video encoder (e.g., video encoder (200)) partitions the picture into multiple coding tree units (CTUs). The video encoder (200) may partition the CTUs according to a tree structure such as a quadtree-binary tree (QTBT) structure or a Multi-Type Tree (MTT) structure. The QTBT structure eliminates the concepts of multiple partitioning types, such as the separation between CUs, PUs, and TUs in HEVC. The QTBT structure includes two levels: a first level partitioned according to quadtree partitioning, and a second level partitioned according to binary tree partitioning. The root node of the QTBT structure corresponds to a CTU. The leaf nodes of the binary trees correspond to coding units (CUs).

[0055] In an MTT partitioning structure, blocks can be partitioned using quadtree (QT) partitions, binary tree (BT) partitions, and one or more types of triple tree (TT) (also referred to as ternary tree (TT)) partitions. A triple or ternary tree partition is a partition in which a block is divided into three sub-blocks. In some examples, a triple or ternary tree partition divides the block into three sub-blocks without dividing the original block through the center. The partitioning types of MTT (e.g., QT, BT, and TT) can be symmetric or asymmetric.

[0056] In some examples, the video encoder (200) and the video decoder (300) may use a single QTBT or MTT structure to represent each of the luminance and chrominance components, whereas in other examples, the video encoder (200) and the video decoder (300) may use two or more QTBT or MTT structures, such as one QTBT / MTT structure for the luminance component and another QTBT / MTT structure for both of the chrominance components (or two QTBT / MTT structures for each chrominance component).

[0057] The video encoder (200) and video decoder (300) may be configured to use quadtree partitioning per HEVC, QTBT partitioning, MTT partitioning, or other partitioning structures. For the purpose of explanation, the description of the techniques of the present disclosure is presented in relation to QTBT partitioning. However, it should be understood that the techniques of the present disclosure may also be applied to video coders configured to use quadtree partitioning or other types of partitioning.

[0058] Blocks (e.g., CTUs or CUs) can be grouped in various ways within a picture. For example, a brick may refer to a rectangular area of ​​rows of CTUs within a specific tile in a picture. A tile may be a rectangular area of ​​CTUs within a specific tile column and a specific tile row in a picture. A tile column refers to a rectangular area of ​​CTUs having a height equal to the height of the picture and a width specified by syntax elements (e.g., in a picture parameter set). A tile row refers to a rectangular area of ​​CTUs having a width equal to the width of the picture and a height specified by syntax elements (e.g., in a picture parameter set).

[0059] In some examples, a tile may be partitioned into multiple bricks, each of which may contain one or more CTU rows within the tile. A tile that is not partitioned into multiple bricks may also be referred to as a brick. However, a brick, which is a true subset of a tile, may not be referred to as a tile.

[0060] Bricks within a picture can also be arranged into slices. A slice may be an integer number of bricks in the picture that can be exclusively contained in a single network abstraction layer (NAL) unit. In some examples, a slice contains multiple complete tiles, or only a continuous sequence of complete bricks of a single tile.

[0061] The present disclosure may refer to the sample dimensions of a block (e.g., a CU or other video block) using "NxN" and "N-to-N" interchangeably in terms of vertical and horizontal dimensions (e.g., 16x16 samples or 16-to-16 samples). Generally, a 16x16 CU will have 16 samples in the vertical direction (y = 16) and 16 samples in the horizontal direction (x = 16). Similarly, an NxN CU generally has N samples in the vertical direction and N samples in the horizontal direction, where N represents a non-negative integer value. Samples within a CU may be arranged in rows and columns. Additionally, CUs do not necessarily have the same number of samples in the horizontal direction as in the vertical direction. For example, CUs may contain NxM samples, where M is not necessarily equal to N.

[0062] A video encoder (200) encodes video data for CUs that represent prediction and / or residual information and other information. The prediction information indicates how the CU should be predicted to form a prediction block for the CU. The residual information generally represents sample-by-sample differences between the samples of the CU prior to encoding and the prediction block.

[0063] To predict the CU, the video encoder (200) can generally form a prediction block for the CU through inter-prediction or intra-prediction. Inter-prediction generally refers to predicting the CU from data of a previously coded picture, whereas intra-prediction generally refers to predicting the CU from data of the same picture previously coded. To perform inter-prediction, the video encoder (200) can generate a prediction block using one or more motion vectors. The video encoder (200) can generally perform a motion search to identify a reference block that closely matches the CU, for example, in terms of the differences between the CU and the reference block. The video encoder (200) can determine whether the reference block closely matches the current CU by calculating a difference metric using SAD (sum of absolute difference), SSD (sum of squared differences), MAD (mean absolute difference), MSD (mean squared differences), or other such difference calculations. In some examples, the video encoder (200) can predict the current CU using unidirectional prediction or bidirectional prediction.

[0064] Some examples of JEM and VVC also provide an affine motion compensation mode that can be considered as an inter-prediction mode. In an affine motion compensation mode, the video encoder (200) can determine two or more motion vectors representing non-translational motion, such as zoom in or zoom out, rotation, perspective motion, or other irregular motion types.

[0065] To perform intra-prediction, the video encoder (200) may generate prediction blocks by selecting an intra-prediction mode. Some examples of JEM and VVC provide 67 intra-prediction modes, including planar mode and DC mode, as well as various directional modes. Generally, the video encoder (200) selects an intra-prediction mode that describes samples adjacent to the current block (e.g., a block of CUs) to predict samples of the current block. Such samples may generally be located above, above to the left, or to the right of the current block in the same picture as the current block, assuming the video encoder (200) codes the CTUs and CUs in raster scan order (from left to right, from top to bottom).

[0066] The video encoder (200) encodes data representing the prediction mode for the current block. For example, in the case of inter-prediction modes, the video encoder (200) can encode motion information for the corresponding mode as well as data representing which of the various available inter-prediction modes is used. In the case of unidirectional or bidirectional inter-prediction, for example, the video encoder (200) can encode motion vectors using AMVP (advanced motion vector prediction) or merge mode. The video encoder (200) can encode motion vectors for the affine motion compensation mode using similar modes.

[0067] After prediction, such as intra-prediction or inter-prediction of a block, the video encoder (200) can calculate residual data for the block. Residual data, such as residual blocks, represents sample-by-sample differences between the block and the prediction block for the block, formed using the corresponding prediction mode. The video encoder (200) can apply one or more transformations to the residual blocks to generate transformed data in a transformation domain instead of a sample domain. For example, the video encoder (200) can apply a discrete cosine transform (DCT), integer transform, wavelet transform, or conceptually similar transformation to the residual video data. Additionally, the video encoder (200) can apply a secondary transformation after the primary transformation, such as a mode-dependent non-separable secondary transform (MDNSST), signal-dependent transform, or Karhunen-Loeve transform (KLT). The video encoder (200) generates transformation coefficients after applying one or more transformations.

[0068] As described above, after any transformations to generate transformation coefficients, the video encoder (200) may perform quantization of the transformation coefficients. Quantization generally refers to a process in which transformation coefficients are quantized to provide additional compression, so as to reduce the amount of data used to represent the transformation coefficients. By performing the quantization process, the video encoder (200) may reduce the bit depth associated with some or all of the transformation coefficients. For example, the video encoder (200) may round down an n-bit value to an m-bit value during quantization, where n is greater than m. In some examples, to perform quantization, the video encoder (200) may perform a bitwise right-shift of the value to be quantized.

[0069] After quantization, the video encoder (200) can scan the transform coefficients to generate a one-dimensional vector from a two-dimensional matrix containing the quantized transform coefficients. The scan can be designed to place higher energy (and consequently, lower frequency) transform coefficients at the front of the vector and lower energy (and consequently, higher frequency) transform coefficients at the rear of the vector. In some examples, the video encoder (200) can generate a serialized vector using a predefined scan order to scan the quantized transform coefficients, and then entropy-encode the quantized transform coefficients of the vector. In other examples, the video encoder (200) can perform an adaptive scan. After scanning the quantized transform coefficients to form a one-dimensional vector, the video encoder (200) can entropy-encode the one-dimensional vector according to, for example, context-adaptive binary arithmetic coding (CABAC). The video encoder (200) can also entropy-encode values ​​for syntax elements describing metadata associated with encoded video data for use by the video decoder (300) in decoding video data.

[0070] To perform CABAC, the video encoder (200) may assign a context within a context model to the symbol to be transmitted. The context may, for example, relate to whether the neighboring values ​​of the symbol are zero values ​​or not. The probability determination may be based on the context assigned to the symbol.

[0071] The video encoder (200) may additionally generate syntax data, such as block-based syntax data, picture-based syntax data, and sequence-based syntax data to the video decoder (300) from, for example, a picture header, a block header, a slice header, or other syntax data, such as an SPS (sequence parameter set), a PPS (picture parameter set), or a VPS (video parameter set). The video decoder (300) may likewise decode such syntax data to determine how to decode the corresponding video data.

[0072] In this way, the video encoder (200) can generate a bitstream containing encoded video data, such as syntax elements describing the partitioning of a picture into blocks (e.g., CUs), and prediction and / or residual information for the blocks. Ultimately, the video decoder (300) can receive the bitstream and decode the encoded video data.

[0073] Generally, the video decoder (300) performs a reciprocal process to decode the encoded video data of the bitstream as performed by the video encoder (200). For example, the video decoder (300) can decode values ​​for the syntax elements of the bitstream using CABAC in a substantially similar but reciprocal manner to the CABAC encoding process of the video encoder (200). The syntax elements define the partitioning information of the picture as CTUs, and define the CUs of the CTUs by partitioning each CTU according to a corresponding partition structure, such as a QTBT structure. The syntax elements can additionally define prediction and residual information for blocks of video data (e.g., CUs).

[0074] Residual information may be represented, for example, by quantized transform coefficients. The video decoder (300) can reconstruct a residual block for a block by inversely quantizing and inversely transforming the quantized transform coefficients of the block. The video decoder (300) forms a prediction block for the block using a signaled prediction mode (intra-prediction or inter-prediction) and related prediction information (e.g., motion information for inter-prediction). Then, the video decoder (300) can reconstruct the original block by combining the prediction block and the residual block (sample by sample). The video decoder (300) can perform additional processing to reduce visual artifacts along the boundaries of the block, such as a deblocking process.

[0075] The present disclosure may generally refer to "signaling" specific information, such as syntax elements. The term "signaling" may generally refer to the communication of values ​​for syntax elements and / or other data used to decode encoded video data. That is, the video encoder (200) may signal values ​​for syntax elements in a bitstream. Generally, signaling refers to generating values ​​in a bitstream. As described above, the source device (102) may transmit the bitstream to the destination device (116) in a substantially non-real-time or real-time manner, such as when storing syntax elements in the storage device (112) for subsequent retrieval by the destination device (116).

[0076] FIGS. 2a and 2b are conceptual diagrams illustrating an exemplary quadtree binary tree (QTBT) structure (130) and a corresponding coding tree unit (CTU) (132). Solid lines represent quadtree splits, and dotted lines represent binary tree splits. At each split (i.e., non-leaf) node of the binary tree, a flag is signaled to indicate which split type (i.e., horizontal or vertical) is used, where in this example 0 indicates a horizontal split and 1 indicates a vertical split. In the case of a quadtree split, there is no need to indicate the split type because the quadtree nodes split the block horizontally and vertically into four sub-blocks of the same size. Accordingly, the video encoder (200) can encode syntax elements (e.g., partition information) for the region tree levels (i.e., solid lines) of the QTBT structure (130) and syntax elements (e.g., partition information) for the prediction tree levels (i.e., dotted lines) of the QTBT structure (130), and the video decoder (300) can decode them. The video encoder (200) can encode video data, such as prediction and transformation data, for CUs represented by terminal leaf nodes of the QTBT structure (130), and the video decoder (300) can decode them.

[0077] Generally, the CTU (132) of FIG. 2b may be associated with parameters that define the sizes of blocks corresponding to the nodes of the QTBT structure (130) at the first and second levels. These parameters may include CTU size (representing the size of the CTU (132) in the samples), minimum quadtree size (MinQTSize representing the minimum allowed quadtree leaf node size), maximum binary tree size (MaxBTSize representing the maximum allowed binary tree root node size), maximum binary tree depth (MaxBTDepth representing the maximum allowed binary tree depth), and minimum binary tree size (MinBTSize representing the minimum allowed binary tree leaf node size).

[0078] The root node of the QTBT structure corresponding to the CTU may have four child nodes in the first level of the QTBT structure, each of which may be partitioned according to quadtree partitioning. That is, the nodes in the first level are either leaf nodes (no child nodes) or have four child nodes. An example of the QTBT structure (130) illustrates such nodes including parent nodes and child nodes with solid lines for branches. If the nodes in the first level are not larger than the maximum allowable binary tree root node size (MaxBTSize), the nodes may be further partitioned by individual binary trees. The binary tree splitting of a node may be repeated until the nodes resulting from the split reach the minimum allowable binary tree leaf node size (MinBTSize) or the maximum allowable binary tree depth (MaxBTDepth). An example of the QTBT structure (130) illustrates such nodes with dotted lines for branches. Binary tree leaf nodes are referred to as CUs (coding units), which are used for prediction (e.g., intra-picture or inter-picture prediction) and transformation without any additional partitioning. As discussed above, CUs may also be referred to as "video blocks" or "blocks".

[0079] In one example of a QTBT partitioning structure, the CTU size is set to 128x128 (luminance samples and two corresponding 64x64 chroma samples), MinQTSize is set to 16x16, MaxBTSize is set to 64x64, MinBTSize (both width and height) is set to 4, and MaxBTDepth is set to 4. Quadtree partitioning is first applied to the CTU to generate quadtree leaf nodes. Quadtree leaf nodes can have a size of 16x16 (i.e., MinQTSize) to 128x128 (i.e., CTU size). If a leaf quadtree node is 128x128, it will not be further partitioned by the binary tree because its size exceeds MaxBTSize (i.e., 64x64 in this example). Otherwise, the leaf quadtree node will be further partitioned by the binary tree. Therefore, a quadtree leaf node is also the root node of the binary tree and has a binary tree depth of 0. When the binary tree depth reaches MaxBTDepth (4 in this example), further splitting is not allowed. When a binary tree node has a width equal to MinBTSize (4 in this example), it implies that further horizontal splitting is not allowed. Similarly, a binary tree node with a height equal to MinBTSize implies that further vertical splitting is not allowed for that binary tree node. As described above, the leaf nodes of the binary tree are referred to as CUs and are further processed according to prediction and transformation without additional partitioning.

[0080] TCQ (Trellis coded quantization) was proposed in H. Schwarz, T. Nguyen, D. Marpe, T. Wiegand, M. Karczewicz, M. Coban, J. Dong, "CE7: Transform coefficient coding with reduced number of regular-coded bins (tests 7.1.3a, 7.1.3b)", JVET document JVET-L0274, Macao, CN, Oct 2018 (hereinafter, JVET-L0274). In the techniques of JVET-L0274, two scalar quantizers are used switchably for quantization / de-quantization. The scalar quantizer used for the current transformed / quantized coefficient is determined by the parity (lesser bit) of the quantized coefficient preceding the current transformed / quantized coefficient in scanning order.

[0081] A transform coefficient coding scheme coupled with TCQ is also proposed in JVET-L0274, whereby the context selection for decoding the quantized coefficients depends on the quantizer used. Specifically, the significance flag (SIG) of a transform coefficient, which indicates whether the transform coefficient is zero or not zero, can be coded into one of three sets of context models, and the set selected for a specific SIG depends on the quantizer used for the associated coefficient. Thus, when starting the decoding of the SIG of the current coefficient, the entropy decoder (e.g., the entropy decoder of the video decoder (300)) determines the parity of the transform coefficient at the previous scanning position, which determines the quantizer for the context set for the current coefficient and the consequent SIG of that coefficient.

[0082] In some examples, the TU is divided into non-overlapping subblocks (referred to as coding groups (CGs)), and their size is typically 4x4 samples. The decoding process described herein may sometimes be described in relation to 4x4 CGs, but can be extended to any other CG sizes. The techniques of this disclosure, and the descriptions contained herein, are primarily related to encoding and decoding processes for absolute levels of transform factors in CGs. Other information associated with CGs, such as codes, may be encoded or decoded in the manner described in JVET-L0274, but may also be encoded and decoded using alternative techniques.

[0083] The video encoder (200) and video decoder (300) may be configured to process syntax elements in bitstreams. For example, the following syntax elements may be used to represent the absolute level value (absLevel) for a transform factor. Note that quantized transform coeffects typically have integer values. The absolute level is the magnitude of the transform factor. · sig_coeff_flag (SIG): If absLevel is 0, this flag is equal to 0; otherwise, the flag is equal to 1. · abs_level_gt1_flag: If sig_coeff_flag is equal to 1, this flag is present in the bitstream. If absLevel is greater than 1, the value of abs_level_gt1_flag is equal to 1; otherwise, abs_level_gt1_flag is equal to 0. · par_level_flag: If abs_level_gt1_flag is equal to 1, this flag is present in the bitstream. The value of par_level_flag is equal to 0 if absLevel is odd, and equal to 1 if absLevel is even. · abs_level_gt3_flag: If abs_level_gt1_flag is equal to 1, this flag is present in the bitstream. If absLevel is greater than 3, the value of abs_level_gt3_flag is equal to 1; otherwise, abs_level_gt3_flag is equal to 0. · abs_remainder: If abs_level_gt3_flag is equal to 1, this syntax element exists in the bitstream. The abs_remainder syntax element is the absolute remainder of the transform factor level coded in Golomb-Rice. · abs_level: This is the absolute value of the transformation factor level coded in Golomb-Rice.

[0084] Below, the syntax elements sig_coeff_flag, par_level_flag, abs_level_gt1_flag, abs_level_gt3_flag, abs_remainder, and abs_level are denoted as SIG, Par, Gt1, Gt2, remLevel, and absLevel, respectively, for brevity of description.

[0085] The video encoder (200) and video decoder (300) may be configured to set any of the above syntax elements that are not parsed from the bitstream to a default value such as 0. Given the values ​​of the first of the five syntax elements, the value for the absolute level of the transform factor can be calculated as follows:

[0086] Alternatively, if the transformation coefficients are fully coded in bypass-coded mode, absoluteLevel can be directly coded as abs_level.

[0087] FIG. 3 illustrates an exemplary sequence of syntax elements representing absoluteLevels in a CG as in JVET-L0274. Other sequences may also be used. As can be seen in FIG. 3, when absLevel is greater than 4, all five syntax elements described above are parsed from the bitstream.

[0088] In the example of FIG. 3, the video decoder (300) scans positions in the CG in up to four passes. In the first pass (136), the video decoder (300) parses the values ​​for the SIG, Par, and Gt1 syntax elements. Only non-zero SIGs are followed by corresponding Gt1 and Par syntax elements. That is, if the video decoder (300) determines that the SIG has a value of 0 (meaning that the transform coefficient level is equal to 0), the video decoder (300) does not receive instances of the Gt1 and Par syntax elements for that coefficient. After the first pass (136), for each position, the value for the partial absoluteLevel (denoted as absLevel1) can be restored as shown in Equation (2).

[0089] In some implementations, the video decoder (300) may be configured to parse up to 28 regular coded bins in the first pass (136) for 4x4 subblocks and up to 6 regular coded bins for 2x2 subblocks. Limits on the number of regular coded bins may be enforced in groups of SIG, Gt1, and Par bins, which means that each group of SIG, Gt1, and Par bins is coded as a set, and switching to bypass coding in the middle of a set is not allowed. That is, in some implementations, every syntax element of the SIG, Gt1, and Par set is coded as a regular coded bin (e.g., context coded) or coded in bypass mode.

[0090] If at least one non-zero Gt1 exists in the first pass (136), the video decoder (300) may be configured to scan the second pass (138). In the second pass (138), the video decoder (300) parses Gt2 syntax elements for positions in the CG that have non-zero Gt1 syntax elements. The positions in the CG are associated with transform coefficients. The bins in the first pass (136) and the second passes (138) may all be normalized, which means that the probability distribution of the bins is modeled by a selected context model. If at least one non-zero Gt2 syntax element exists in the second pass (138), the video decoder (300) scans the third pass (140). During the third pass (140), the video decoder (300) parses the remLevel syntax elements of positions having non-zero Gt2s. The remLevel syntax elements are not binary, and the video decoder (300) can bypass code the binaries of the remLevel binary version, which means that the binaries are assumed to be uniformly distributed and no context selection is required.

[0091] In the fourth pass (142), the video decoder (300) scans all remaining coefficients that were not partially represented by the normally coded bins in the previous three passes. The transform coefficient levels of the fourth pass (142) are coded into absolute values ​​using bypass coded bins.

[0092] The video encoder (200) and video decoder (300) may perform context modeling to entropy-code some of the syntax elements described above. The context modeling used in JVET-L0274 is also briefly introduced here, along with modifications proposed by this disclosure. The context modeling discussed in more detail below generally refers to the selection of probabilistic models (also referred to as contexts) for bins being encoded or decoded. In JVET-L0274, the syntax elements SIG, Par, Gt1, and Gt2 are coded using context modeling. The selection of contexts depends on the values ​​of the absLevel1 syntax elements in the local neighborhood, denoted by N. Positions that are inside the template but are currently outside the TU may be excluded from N.

[0093] Figure 4 illustrates an example of a template used to select probabilistic models. Squares marked with "X" specify the current scan position, and squares marked with "Y" represent the local neighborhoods used.

[0094] For the current position (refer to the square with X in FIG. 4), the video decoder (300) determines the context indices of the SIG, Par, Gt1, and Gt2 syntax elements, denoted as ctxIdxSIG, ctxIdxPar, ctxIdxGt1, and ctxIdxGt2. To determine the context indices, the video decoder (300) may first determine three variables — numSIG, sumAbs1, and d —. The variable numSIG represents the number of non-zero SIGs in N, which is expressed by the following formula (3):

[0095] The variable sumAbs1 represents the sum of absLevel1 in N, which is expressed by the following formula (4):

[0096] The variable d represents the diagonal measurement of the current position inside the TU, as expressed by the following formula (5): Here, x and y represent the coordinates of the current position inside the TU.

[0097] Given sumAbs1 and d, the video decoder (300) determines a context index for decoding SIG as follows: · In the case of luma, ctxIdxSIG is determined by formula (6): · For chroma, ctxIdxSIG is determined by formula (7):

[0098] In equations (6) and (7), the variable "state" represents the current state of the state machine as defined in JVET-L0274. State machines are discussed in more detail below.

[0099] Given sumSIG, sumAbs1, and d, the video decoder (300) determines a context index for decoding Par as follows: · If the current scan position is the same as the position of the last non-zero coefficient, ctxIdxPar is 0. · Otherwise, o In the case of Luma, ctxIdxPar is determined by formula (8): o For chroma, ctxIdxPar is determined by (9): ctxIdxGt1 and ctxIdxGt2 are set to the values ​​of ctxIdxPar.

[0100] The video encoder (200) and video decoder (300) may be configured to perform RemLevel coding. The video decoder (300) derives Rice parameters (ricePar) for coding the non-binary syntax elements remRemainder (remLevel) and absLevel as follows: · At the beginning of each subblock, ricePar is set to 0; · After coding the syntax elements for the rest, the Rice parameter (ricePar) is modified as follows: ricePar is less than 3 and the last coded remainder value If it is greater than, ricePar is incremented by 1.

[0101] To code the non-binary syntax element absLevel representing completely bypass-coded absolute quantization indices, the following is applied: · The sum of the absolute values ​​in the local template is determined. · The variables ricePar and posZero are determined by a table lookup according to the following, and Here, the variable state represents the state of dependent quantization (which is equal to 0 when dependent quantization is disabled), and the tables riceParTable[] and posZeroTable[][] are given as follows. · The intermediate variable codeValue is derived as follows: If absLevel is equal to 0, codeValue is set to be equal to posZero; o Otherwise, if absLevel is less than or equal to posZero, codeValue is set to absLevel - 1; o Otherwise (absLevel is greater than posZero), codeValue is set to be the same as absLevel. · The value of codeValue is coded using the Golomb-Rice code together with the Rice parameter ricePar.

[0102] The video encoder (200) and video decoder (300) may be configured to perform a combination of Golomb-Rice coding and exponential Golomb coding for the remainder level coding. That is, the portion of the transform coefficient levels that are not context-coded may be represented by a combination of Golomb-Rice and exponential Golomb codes. The portion of the transform coefficients that are not context-coded may correspond to the values ​​for remLevel or absLevel discussed above.

[0103] When coding level values ​​for coefficients, level values ​​that are not context-coded are generally expected to be relatively small. Accordingly, the present disclosure proposes using Golomb-Rice coding, which can be an efficient coding technique for coding small values. In such cases where the level values ​​for the transformation coefficients are not small, exponential Golomb coding may be used, which can be an efficient coding technique for coding larger values.

[0104] For the remaining coefficient values, the switching point for transitioning from Golomb-Rice to exponential Golomb coding can be determined based on the following thresholds: Here, m_goRicePar is the Rice parameter, and This is a lookup table that determines the prefix lengths (i.e., length -1) for each Rice parameter. Coefficient values ​​that are less than or equal to the threshold can be coded using Golomb-Rice codes, whereas coefficient values ​​greater than the threshold can be coded using both Golomb-Rice codes and exponential Golomb codes.

[0105] The video decoder (300) may be configured to perform absoluteLevel restoration, which generally refers to a process of determining level values ​​based on various syntax elements. absoluteLevel restoration is the same as that in JVET-L0274 discussed above with respect to syntax elements in the bitstream.

[0106] The present disclosure describes techniques for remainder level coding. According to the techniques of the present disclosure, a video encoder (200) and a video decoder (300) may be configured to use a fixed prefix length (defined by RiceRange for all Rice parameters) to determine the transition point between the use of Golomb-Rice and exponential Golomb codes. In one example, the threshold will be as follows:

[0107] Values ​​of 5 or 6 for RiceRange can provide good results in terms of coding performance in current VVC designs. The techniques of the present disclosure can, for example, eliminate the need to use lookup tables without excessively sacrificing coding efficiency.

[0108] In some examples, different RiceRanges may be used for coding the remLevel and absLevel parts of the transformation coefficients because remLevel represents half of the remaining levels while absLevel represents the entire level (larger values).

[0109] In other examples, the video encoder (200) and the video decoder (300) may be configured to use a fixed RiceRange parameter, such as 5 or 6, for all Rice parameters except the largest Rice parameter, which may have a smaller RiceRange parameter such as 3.

[0110] The techniques of the present disclosure include the proposed worst-case escape code length limit. Current Golomb-Rice / exponent GolombGolomb representations for the remaining count levels may exceed 32 bits in length. For example, in the worst case where riceParam=0, remLevel codes may have a maximum value of 16381, represented by 33 bits. For absLevel, 215 The maximum value of is represented by 35 bits. The present disclosure proposes techniques to limit the worst-case code length to 32.

[0111] The maximum prefix code length is given by: When this prefix length is reached, the corresponding suffix length is given by the following: This method limits the worst-case escape code length to 32 bits for coding abs_remainder(remLevel) and dec_abs_level(absLevel) syntax elements.

[0112] The table below shows the proposed binaryization cRiceParam = 0.

[0113] In the table above, the input value 5 represents the switching point between Golomb Rice coding and exponential Golomb coding. The codeword for the input value can be viewed as the Golomb Rice code 11111 with a 0 added, corresponding to 5 + 0. The next input, 6, can be viewed as the Golomb Rice code 11111 with a 10x added, corresponding to 5 + 1 = 6. Similarly, the remaining inputs can be viewed as the sum of the Golomb Rice code 11111 and the exponential Golomb value.

[0114] The table below generally shows the same coding method as above, but with the proposed binary cRiceParam = 1.

[0115] The table below generally shows the same coding method as above, but with the proposed binary cRiceParam = 2.

[0116] The table below generally shows the same coding method as above, but with the proposed binary cRiceParam = 3.

[0117] FIG. 5 is a block diagram illustrating an exemplary video encoder (200) capable of performing the techniques of the present disclosure. FIG. 5 is provided for illustrative purposes and should not be considered a limitation of the techniques as roughly illustrated and described in the present disclosure. For illustrative purposes, the present disclosure describes the video encoder (200) in the context of video coding standards such as the HEVC video coding standard and the H.266 video coding standard currently under development. However, the techniques of the present disclosure are not limited to these video coding standards and are generally applicable to video encoding and decoding.

[0118] In the example of FIG. 5, the video encoder (200) includes a video data memory (230), a mode selection unit (202), a residual generation unit (204), a conversion processing unit (206), a quantization unit (208), an inverse quantization unit (210), an inverse conversion processing unit (212), a restoration unit (214), a filter unit (216), a DPB (decoded picture buffer) (218), and an entropy encoding unit (220).

[0119] The video data memory (230) can store video data to be encoded by the components of the video encoder (200). The video encoder (200) can receive video data stored in the video data memory (230) from, for example, a video source (104) (Fig. 1). The DPB (218) can serve as a reference picture memory that stores reference video data for use in predicting subsequent video data by the video encoder (200). The video data memory (230) and the DPB (218) can be formed by any of various memory devices, such as dynamic random access memory (DRAM), including SDRAM (synchronous DRAM), MRAM (magnetoresistive RAM), RRAM (resistive RAM), or other types of memory devices. The video data memory (230) and the DPB (218) can be provided by the same memory device or by separate memory devices. In various examples, the video data memory (230) may be on-chip with other components of the video encoder (200) as exemplified, or off-chip with respect to such components.

[0120] In the present disclosure, a reference to the video data memory (230) should not be interpreted as being limited to memory inside the video encoder (200) or memory outside the video encoder (200) unless specifically described as such. Rather, a reference to the video data memory (230) should be understood as a reference memory that stores video data received by the video encoder (200) for encoding (e.g., video data for the current block to be encoded). The memory (106) of FIG. 1 may also provide temporary storage of outputs from various units of the video encoder (200).

[0121] Various units of FIG. 5 are illustrated to aid in understanding the operations performed by the video encoder (200). The units may be implemented as fixed-function circuits, programmable circuits, or a combination thereof. Fixed-function circuits refer to circuits that provide specific functionality and are pre-set for the operations that can be performed. Programmable circuits refer to circuits that can be programmed to perform various tasks and provide flexible functionality in the operations that can be performed. For example, programmable circuits may execute software or firmware that causes the programmable circuits to operate in a manner defined by the commands of the software or firmware. Fixed-function circuits may execute software commands (e.g., to receive parameters or to output parameters), but the types of operations performed by the fixed-function circuits generally cannot be changed. In some examples, one or more units may be separate circuit blocks (fixed-function or programmable), and in some examples, one or more units may be integrated circuits.

[0122] The video encoder (200) may include arithmetic logic units (ALUs), elementary function units (EFUs), digital circuits, analog circuits, and / or programmable cores formed from programmable circuits. In examples where the operations of the video encoder (200) are performed using software executed by programmable circuits, memory (106) (FI. 1) may store object code of software that the video encoder (200) receives and executes, or another memory (not shown) within the video encoder (200) may store such instructions.

[0123] The video data memory (230) is configured to store received video data. The video encoder (200) can retrieve a picture of video data from the video data memory (230) and provide the video data to the residual generation unit (204) and the mode selection unit (202). The video data in the video data memory (230) may be raw video data to be encoded.

[0124] The mode selection unit (202) includes a motion estimation unit (222), a motion compensation unit (224), and an intra-prediction unit (226). The mode selection unit (202) may include additional function units for performing video prediction according to different prediction modes. As examples, the mode selection unit (202) may include a palette unit, an intra-block copy unit (which may be part of the motion estimation unit (222) and / or the motion compensation unit (224)), an affine unit, a linear model (LM) unit, etc.

[0125] The mode selection unit (202) generally adjusts a number of encoding passes to test combinations of encoding parameters and resulting rate-distortion values ​​for such combinations. Encoding parameters may include partitioning of CTUs into CUs, prediction modes for CUs, transformation types for residual data of CUs, quantization parameters for residual data of CUs, etc. The mode selection unit (202) can ultimately select a combination of encoding parameters that has better rate-distortion values ​​than other tested combinations.

[0126] The video encoder (200) can partition a picture retrieved from the video data memory (230) into a series of CTUs and encapsulate one or more CTUs within a slice. The mode selection unit (202) can partition the CTUs of the picture according to a tree structure, such as the QTBT structure of HEVC or the quadtree structure described above. As described above, the video encoder (200) can form one or more CUs by partitioning the CTUs according to the tree structure. Such CUs may also generally be referred to as "video blocks" or "blocks".

[0127] Generally, the mode selection unit (202) also controls its components (e.g., motion estimation unit (222), motion compensation unit (224), and intra-prediction unit (226)) to generate a prediction block for the current block (e.g., the current CU, or the overlapping portion of PU and TU in HEVC). For inter-prediction of the current block, the motion estimation unit (222) may perform a motion search to identify one or more closely matching reference blocks from one or more reference pictures (e.g., one or more previously coded pictures stored in the DPB (218). In particular, the motion estimation unit (222) may calculate a value expressing how similar a potential reference block is to the current block according to, for example, SAD (sum of absolute difference), SSD (sum of squared differences), MAD (mean absolute difference), MSD (mean squared differences), etc. The motion estimation unit (222) can perform these calculations using sample-by-sample differences between the current block and the reference block that are generally considered. The motion estimation unit (222) can identify the reference block having the lowest value resulting from these calculations, which indicates the reference block that matches most closely with the current block.

[0128] The motion estimation unit (222) may form one or more motion vectors (MVs) that define the positions of reference blocks in reference pictures for the position of the current block in the current picture. Then, the motion estimation unit (222) may provide the motion vectors to the motion compensation unit (224). For example, in the case of unidirectional inter-prediction, the motion estimation unit (222) may provide a single motion vector, whereas in the case of bidirectional inter-prediction, the motion estimation unit (222) may provide two motion vectors. Then, the motion compensation unit (224) may generate a prediction block using the motion vectors. For example, the motion compensation unit (224) may retrieve data of the reference block using the motion vectors. As another example, if the motion vector has fractional sample precision, the motion compensation unit (224) may interpolate values ​​for the prediction block according to one or more interpolation filters. Furthermore, for bidirectional inter-prediction, the motion compensation unit (224) can retrieve data for two reference blocks identified by individual motion vectors and combine the retrieved data, for example, through sample-by-sample averaging or weighted averaging.

[0129] As another example, for intra-prediction or intra-prediction coding, the intra-prediction unit (226) can generate prediction blocks from samples adjacent to the current block. For example, in the case of directional modes, the intra-prediction unit (226) can generally generate prediction blocks by mathematically combining the values ​​of neighboring samples and populating these calculated values ​​in a direction defined across the current block. As another example, in the case of DC mode, the intra-prediction unit (226) can calculate the average of neighboring samples for the current block and generate prediction blocks to include this resulting average for each sample of the prediction block.

[0130] The mode selection unit (202) provides the prediction block to the residual generation unit (204). The residual generation unit (204) receives a raw, uncoded version of the current block from the video data memory (230) and receives the prediction block from the mode selection unit (202). The residual generation unit (204) calculates the sample-by-sample differences between the current block and the prediction block. The resulting sample-by-sample differences define the residual block for the current block. In some examples, the residual generation unit (204) may also determine the differences between sample values ​​in the residual block to generate the residual block using residual differential pulse code modulation (RDPCM). In some examples, the residual generation unit (204) may be formed using one or more subtractor circuits that perform binary subtraction.

[0131] In examples where the mode selection unit (202) partitions the CUs into PUs, each PU may be associated with a luminance prediction unit and a corresponding chroma prediction unit. The video encoder (200) and the video decoder (300) may support PUs of various sizes. As indicated above, the size of the CU may refer to the size of the luminance coding block of the CU, and the size of the PU may refer to the size of the luminance prediction unit of the PU. Assuming that the size of a particular CU is 2Nx2N, the video encoder (200) may support PU sizes of 2Nx2N or NxN for intra-prediction, and symmetric PU sizes of 2Nx2N, 2NxN, Nx2N, NxN, or similar for inter-prediction. The video encoder (200) and video decoder (30) can also support asymmetric partitioning for PU sizes of 2NxnU, 2NxnD, nLx2N, and nRx2N for inter-prediction.

[0132] In examples where the mode selection unit does not further partition the CU into PUs, each CU may be associated with a luminance coding block and a corresponding chroma coding block. As such, the size of the CU may refer to the size of the luminance coding block of the CU. The video encoder (200) and the video decoder (120) may support CU sizes of 2Nx2N, 2NxN, or Nx2N.

[0133] For other video coding techniques such as intra-block copy mode coding, affine mode coding, and linear model (LM) mode coding, as some examples, the mode selection unit (202) generates a prediction block for the current block being encoded through individual units associated with the coding techniques. In some examples, such as palette mode coding, the mode selection unit (202) may not generate a prediction block and instead may generate syntax elements indicating a method for restoring the block based on a selected palette. In such modes, the mode selection unit (202) may provide these syntax elements to the entropy encoding unit (220) to be encoded.

[0134] As described above, the residual generation unit (204) receives video data for the current block and the corresponding prediction block. Then, the residual generation unit (204) generates a residual block for the current block. To generate the residual block, the residual generation unit (204) calculates the sample-by-sample differences between the prediction block and the current block.

[0135] The transformation processing unit (206) applies one or more transformations to the remaining block to create a block of transformation coefficients (referred to herein as a “transformation coefficient block”). The transformation processing unit (206) may form the transformation coefficient block by applying various transformations to the remaining block. For example, the transformation processing unit (206) may apply a discrete cosine transform (DCT), a directional transformation, a Karhunen-Loeve transform (KLT), or a conceptually similar transformation to the remaining block. In some examples, the transformation processing unit (206) may perform a number of transformations on the remaining block, such as a first transformation and a second transformation, such as a rotation transformation. In some examples, the transformation processing unit (206) does not apply transformations to the remaining block.

[0136] The quantization unit (208) can quantize the transformation coefficients in the transformation coefficient block to create a quantized transformation coefficient block. The quantization unit (208) can quantize the transformation coefficients of the transformation coefficient block according to the quantization parameter (QP) value associated with the current block. The video encoder (200) can adjust the degree of quantization applied to the transformation coefficient blocks associated with the current block by adjusting the QP value associated with the CU (e.g., via the mode selection unit (202)). Quantization can introduce a loss of information, and accordingly, the quantized transformation coefficients may have lower precision than the original transformation coefficients generated by the transformation processing unit (206).

[0137] The inverse quantization unit (210) and the inverse transformation processing unit (212) can apply the inverse quantization and inverse transformations, respectively, to the quantized transformation coefficient block to restore the residual block from the transformation coefficient block. The restoration unit (214) can generate a restored block corresponding to the current block (which may potentially have some degree of distortion) based on the restored residual block and the prediction block generated by the mode selection unit (202). For example, the restoration unit (214) can add samples of the restored residual block to corresponding samples from the prediction block generated by the mode selection unit (202) to generate the restored block.

[0138] The filter unit (216) may perform one or more filter operations on the restored blocks. For example, the filter unit (216) may perform deblocking operations to reduce blocking artifacts along the edges of the CUs. In some examples, the operations of the filter unit (216) may be skipped.

[0139] The video encoder (200) stores the restored blocks in the DPB (218). For example, in examples where the operations of the filter unit (216) are skipped, that is, in examples where filtering is not performed, the restoration unit (214) can store the restored blocks in the DPB (218). In examples where the operations of the filter unit (216) are performed, the filter unit (216) can store the filtered restored blocks in the DPB (218). The motion estimation unit (222) and the motion compensation unit (224) can inter-predict blocks of subsequently encoded pictures by retrieving a reference picture formed from the restored (and potentially filtered) blocks from the DPB (218). Additionally, the intra-prediction unit (226) can intra-predict other blocks in the current picture using the restored blocks from the DPB (218) of the current picture.

[0140] Generally, the entropy encoding unit (220) can entropy encode syntax elements received from other functional components of the video encoder (200), including the syntax elements described above for coefficient coding. The entropy encoding unit (220) can entropy encode the syntax elements discussed above for signaling, for example, transform coefficients. For example, the entropy encoding unit (220) can entropy encode quantized transform coefficient blocks from the quantization unit (208). As another example, the entropy encoding unit (220) can entropy encode prediction syntax elements from the mode selection unit (202) (e.g., motion information for inter-prediction or intra-mode information for intra-prediction). The entropy encoding unit (220) may perform one or more entropy encoding operations on syntax elements (another example of video data) to generate entropy-encoded data. For example, the entropy encoding unit (220) may perform a context-adaptive variable length coding (CAVLC) operation, a CABAC operation, a variable-to-variable length coding (V2V) operation, a syntax-based context-adaptive binary arithmetic coding (SBAC) operation, a probability interval partitioning entropy (PIPE) coding operation, an exponential-Golomb encoding operation, or other types of entropy encoding operations on the data. In some examples, the entropy encoding unit (220) may operate in a bypass mode where syntax elements are not entropy encoded.

[0141] The video encoder (200) can output a bitstream containing entropy-encoded syntax elements necessary to restore blocks of slices or pictures. In particular, the entropy encoding unit (220) can output a bitstream.

[0142] The actions described above are described in relation to blocks. Such descriptions should be understood as actions for Luma Coding Blocks and / or Chroma Coding Blocks. As described above, in some examples, Luma Coding Blocks and Chroma Coding Blocks are Luma and Chroma components of CU. In some examples, Luma Coding Blocks and Chroma Coding Blocks are Luma and Chroma components of PU.

[0143] In some examples, operations performed with respect to the luminance coding block do not need to be repeated for the chroma coding block. As an example, operations to identify the motion vector (MV) and reference picture for the luminance coding block do not need to be repeated to identify the MV and reference picture for the chroma blocks. Rather, the MV for the luminance coding block can be scaled to determine the MV for the chroma blocks, and the reference picture can be the same. As another example, the intra-prediction process can be the same for the luminance coding block and the chroma coding block.

[0144] A video encoder (200) represents an example of a device configured to encode video data, comprising a memory configured to store video data and one or more processing units implemented in a circuit and configured to encode coefficients as described in the present disclosure.

[0145] A video encoder (200) may, for example, perform a first encoding pass for first syntax elements of a group of transform factors — the first syntax elements correspond to a first set of factors in the group of transform factors —; perform an additional encoding pass for additional syntax elements of a group of transform factors — the additional syntax elements include at least one syntax element indicating the remaining level of the transform factors of the first set of factors —; and process at least one syntax element indicating the remaining level of the transform factors according to any technique of the present disclosure. The first syntax elements may, for example, include one or more importance flags, each of which indicates whether the absolute level of the transform factor is equal to 0. The first syntax elements may include one or more parity level flags, each of which indicates whether the transform factor has an even or odd absolute level. The video encoder (200) may also perform a second encoding pass for the second syntax elements of the transform factor group before performing an additional encoding pass.

[0146] The video encoder (200) also represents an example of a device configured to encode video data, comprising a memory configured to store video data, and one or more processing units implemented in a network and configured to determine values ​​for coefficients of a group of transform coefficients and to context-encode syntax elements for a first set of coefficients of a group of transform coefficients until a maximum number of normally coded bins are reached. The context-encoded syntax elements include one or more significance flags indicating whether the absolute level for the transform coefficient is equal to 0, one or more parity level flags indicating whether the transform coefficient has an even or odd absolute level, and one or more first flags indicating whether the transform coefficient has an absolute level greater than 2. To context-encode the syntax elements of a group of transform coefficients, the video encoder (200) may be configured to perform context-adaptive binary arithmetic encoding to encode the syntax elements of a group of transform coefficients.

[0147] The video encoder (200) may be configured to bypass-encode additional syntax elements for a second set of coefficients in a group of transform coefficients in response to reaching a maximum number of normally coded bins. To bypass-encode additional syntax elements, the video encoder (200) determines a level value for the transform coefficients of the second set of coefficients, encodes a prefix value for the transform coefficients using Golomb-Rice coding in response to the level value being greater than a threshold, and encodes a suffix value using exponential Golomb coding in response to the level value being greater than a threshold. The video encoder (200) may determine the suffix value, for example, by subtracting the prefix value from the level value for the transform coefficients. The level value for the transform coefficients may be an absolute level value or a remainder level value.

[0148] To bypass encoding additional syntax elements, the video encoder (200) may also be configured to determine a second level value for a second coefficient of a second set of coefficients, and, in response to the second level value being less than a threshold value, to encode a prefix value for the second coefficient using Golomb-Rice coding without encoding a suffix value for the second coefficient. The threshold value may be a fixed value or a changing value for all coefficients. For example, the video encoder (200) may be configured to determine, for example, a value for a Rice parameter for a transform coefficient, and to determine a threshold value based on the value for the Rice parameter. The threshold value may be, for example, 5 or 6, but other values ​​may also be used.

[0149] FIG. 6 is a block diagram illustrating an exemplary video decoder (300) capable of performing the techniques of the present disclosure. FIG. 6 is provided for illustrative purposes and is not limited to the techniques as roughly illustrated and described in the present disclosure. For illustrative purposes, the present disclosure describes a video decoder (300) described according to the techniques of JEM and HEVC. However, the techniques of the present disclosure may be performed by video coding devices composed of other video coding standards.

[0150] In the example of FIG. 6, the video decoder (300) includes a CPB (coded picture buffer) memory (320), an entropy decoding unit (302), a prediction processing unit (304), an inverse quantization unit (306), an inverse transformation processing unit (308), a restoration unit (310), a filter unit (312), and a DPB (decoded picture buffer) (314). The prediction processing unit (304) includes a motion compensation unit (316) and an intra-prediction unit (318). The prediction processing unit (304) may include additional units for performing predictions according to different prediction modes. As examples, the prediction processing unit (304) may include a palette unit, an intra-block copy unit (which may form part of the motion compensation unit (316)), an affine unit, a linear model (LM) unit, etc. In other examples, the video decoder (300) may include more, fewer, or different functional components.

[0151] The CPB memory (320) can store video data to be decoded by the components of the video decoder (300), such as an encoded video bitstream. The video data stored in the CPB memory (320) can be obtained, for example, from a computer-readable medium (110) (Fig. 1). The CPB memory (320) may include a CPB that stores encoded video data (e.g., syntax elements) from the encoded video bitstream. Additionally, the CPB memory (320) may store video data other than the syntax elements of the encoded picture, such as temporary data representing outputs from various units of the video decoder (300). The DPB (314) generally stores the decoded pictures, and the video decoder (300) can output and / or use them as reference video data when decoding subsequent data or pictures of the encoded video bitstream. CPB memory (320) and DPB (314) may be formed by any of various memory devices, such as synchronous DRAM (SDRAM), magnetic resistive RAM (MRAM), resistive RAM (RRAM), or dynamic random access memory (DRAM) including other types of memory devices. CPB memory (320) and DPB (314) may be provided by the same memory device or by separate memory devices. In various examples, CPB memory (320) may be on-chip with respect to other components of the video decoder (300) or off-chip with respect to such components.

[0152] Additionally or alternatively, in some examples, the video decoder (300) can retrieve coded video data from memory (120) (Fig. 1). That is, the memory (120) can store data as discussed above together with the CPB memory (320). Likewise, the memory (120) can store instructions to be executed by the video decoder (300) when some or all of the functionality of the video decoder (300) is implemented in software so that it is executed by the processing network of the video decoder (300).

[0153] The various units illustrated in FIG. 6 are exemplified to aid in understanding the operations performed by the video decoder (300). The units may be implemented as fixed-function circuits, programmable circuits, or a combination thereof. Similar to FIG. 5, fixed-function circuits refer to circuits that provide specific functionality and are pre-set for the operations that can be performed. Programmable circuits refer to circuits that can be programmed to perform various tasks and provide flexible functionality in the operations that can be performed. For example, programmable circuits may execute software or firmware that causes the programmable circuits to operate in a manner defined by instructions of the software or firmware. Fixed-function circuits may execute software instructions (e.g., to receive parameters or output parameters), but the types of operations performed by the fixed-function circuits generally cannot be changed. In some examples, one or more units may be separate circuit blocks (fixed-function or programmable), and in some examples, one or more units may be integrated circuits.

[0154] The video decoder (300) may include ALUs, EFUs, digital circuits, analog circuits, and / or programmable cores formed from programmable circuits. In examples where the operations of the video decoder (300) are performed by software running on the programmable circuits, on-chip or off-chip memory may store instructions (e.g., object code) of the software that the video decoder (300) receives and executes.

[0155] The entropy decoding unit (302) can receive video data encoded from the CPB and can entropy decode the video data to produce syntax elements including the syntax elements described above for coefficient coding. The prediction processing unit (304), the inverse quantization unit (306), the inverse transform processing unit (308), the restoration unit (310), and the filter unit (312) can generate decoded video data based on the syntax elements extracted from the bitstream.

[0156] Generally, the video decoder (300) restores the picture block by block. The video decoder (300) can perform the restoration operation individually for each block (where the block currently being restored, i.e., decoded, may be referred to as the "current block").

[0157] The entropy decoding unit (302) can entropy decode conversion information, such as QP (quantization parameter) and / or conversion mode indicator(s), as well as syntax elements defining the quantized conversion coefficients of the quantized conversion coefficient block. The entropy decoding unit (302) can entropy decode the syntax elements discussed above, for example, to signal the conversion coefficients. The dequantization unit (306) can determine the degree of quantization, and likewise, the degree of dequantization for the dequantization unit (306) to be applied, using the QP associated with the quantized conversion coefficient block. The dequantization unit (306) can perform a bit-by-bit left-shift operation to dequantize the quantized conversion coefficients, for example. By doing so, the dequantization unit (306) can form a conversion coefficient block containing the conversion coefficients.

[0158] After the inverse quantization unit (306) forms a transform coefficient block, the inverse transform processing unit (308) may apply one or more inverse transforms to the transform coefficient block to generate a residual block associated with the current block. For example, the inverse transform processing unit (308) may apply an inverse DCT, an inverse integer transform, an inverse KLT (Karhunen-Loeve transform), an inverse rotation transform, an inverse directionality transform, or other inverse transforms to the transform coefficient block.

[0159] In addition, the prediction processing unit (304) generates a prediction block according to the prediction information syntax elements entropy-decoded by the entropy decoding unit (302). For example, if the prediction information syntax elements indicate that the current block is inter-predicted, the motion compensation unit (316) can generate a prediction block. In this case, the prediction information syntax elements may not only indicate the reference picture of the DPB (314) to retrieve the reference block, but also indicate a motion vector identifying the position of the reference block in the reference picture relative to the position of the current block in the current picture. The motion compensation unit (316) can generally perform the inter-predict process in a manner substantially similar to that described in relation to the motion compensation unit (224) (Fig. 5).

[0160] As another example, if the prediction information syntax elements indicate that the current block is intra-predicted, the intra-predict unit (318) can generate a prediction block according to the intra-predict mode indicated by the prediction information syntax elements. Again, the intra-predict unit (318) can generally perform the intra-predict process in a manner substantially similar to that described in relation to the intra-predict unit (226) (Fig. 5). The intra-predict unit (318) can retrieve data of neighbor samples for the current block from the DPB (314).

[0161] The restoration unit (310) can restore the current block using the prediction block and the residual block. For example, the restoration unit (310) can add samples from the residual block to the corresponding samples of the prediction block to restore the current block.

[0162] The filter unit (312) may perform one or more filter operations on the restored blocks. For example, the filter unit (312) may perform deblocking operations to reduce blocking artifacts along the edges of the restored blocks. The operations of the filter unit (312) are not necessarily performed in all examples.

[0163] The video decoder (300) can store the restored blocks in the DPB (314). As discussed above, the DPB (314) can provide reference information, such as samples of the current picture for intra-prediction and previously decoded pictures for subsequent motion compensation, to the prediction processing unit (304). Furthermore, the video decoder (300) can output the decoded pictures from the DPB for subsequent representation on a display device, such as the display device (118) of FIG. 1.

[0164] In this way, the video decoder (300) represents an example of a video decoding device comprising a memory configured to store video data and one or more processing units implemented in a circuit and configured to decode coefficients as described in the present disclosure.

[0165] The video decoder (300) may, for example, perform a first decoding pass for a first syntax element of a group of transform coefficients — the first syntax elements correspond to a first set of coefficients in the group of transform coefficients —; perform an additional decoding pass for additional syntax elements of a group of transform coefficients — the additional syntax elements include at least one syntax element indicating the remaining level of the transform coefficient of the first set of coefficients —; and process at least one syntax element indicating the remaining level of the transform coefficient according to any technique of the present disclosure. The video decoder (300) may determine the value of the transform coefficient based on the first syntax elements and the additional syntax elements.

[0166] The first syntax elements may include, for example, one or more importance flags, each of which indicates whether the absolute level for the transform factor is equal to 0. The first syntax elements may include, for example, one or more parity level flags, each of which indicates whether the transform factor has an even or odd absolute level. The video decoder (300) may also perform a second decoding pass for the second syntax elements of the transform factor group before performing an additional decoding pass.

[0167] In this way, the video decoder (300) also represents an example of a video decoding device comprising a memory configured to store video data, and one or more processing units implemented in a network and configured to context decode syntax elements for a first set of coefficients of a group of transform coefficients until a maximum number of normally coded bins is reached. The context-encoded syntax elements include one or more significance flags indicating whether the absolute level for the transform coefficient is equal to 0, one or more parity level flags indicating whether the transform coefficient has an even or odd absolute level, and one or more first flags indicating whether the transform coefficient has an absolute level greater than 2. To context decode the syntax elements of a group of transform coefficients, the video decoder may be configured to perform context-adaptive binary arithmetic decoding to decode the syntax elements of a group of transform coefficients.

[0168] The video decoder (300) may be configured to bypass decode additional syntax elements for a second set of coefficients in response to reaching a maximum number of normally coded bins. To bypass decode additional syntax elements, the video decoder (300) may be configured to receive a prefix value for a transform coefficient, decode the prefix value using Golomb-Rice coding, receive a suffix value for a transform coefficient in response to the length of the prefix value being equal to a threshold value, and decode the suffix value using exponential Golomb coding.

[0169] The video decoder (300) may be configured to determine values ​​for a first set of coefficients of a conversion unit based on context-decoded syntax elements, and to determine values ​​for a second set of coefficients of a conversion unit based on additional syntax elements. To determine values ​​for a second set of coefficients of a conversion unit based on additional syntax elements, the video decoder (300) may be configured to determine level values ​​for the conversion coefficients based on a decoded prefix value and a decoded suffix value. To determine level values ​​for the conversion coefficients, the video decoder (300) may be configured to add the decoded prefix value to the decoded suffix value. The level values ​​for the conversion coefficients may be absolute level values ​​or remainder level values.

[0170] For the second coefficient, the video decoder (300) may be configured to receive a second prefix value for the second coefficient; decode the second prefix value using Golomb-Rice coding; and, in response to the fact that the length of the second prefix value is less than a threshold value, determine a level value for the second coefficient without receiving a suffix value for the second coefficient.

[0171] The threshold value may be a fixed value or a changing value for all coefficients. For example, the video decoder (300) may be configured to determine, for example, a value for a Rice parameter for a transform coefficient, and to determine a threshold value based on the value for the Rice parameter. The threshold value may be, for example, 5 or 6, but other values ​​may also be used.

[0172] A video decoder may be configured to determine a decoded transform block based on values ​​for a first set of coefficients and values ​​for a second set of coefficients; add the decoded transform block to a prediction block to determine a restored block; perform one or more filtering operations on the restored block to determine a decoded video data block; and output a decoded video data picture containing the decoded video data block.

[0173] FIGS. 7A and 7B illustrate examples of CABAC processes in empty n. In the example (400) of FIG. 7A, the range of empty 2 in empty n is LPS (least probable symbol) (p) when a specific context state (σ) is given. σ Includes RangeMPS and RangeLPS given by the probability of ). Example (400) illustrates the update of the range at bin n+1 when the value of bin n is equal to the MPS (most probable symbol). In this example, the low remains the same, but the value of the range at bin n+1 is reduced to the value of RangeMPS at bin n. Example (402) in FIG. 7b illustrates the update of the range at bin n+1 when the value of bin n is not equal to the MPS (i.e., equal to LPS). In this example, the low is moved to the lower range value of RangeLPS at bin n. Additionally, the value of the range at bin n+1 is reduced to the value of RangeLPS at bin n.

[0174] In one example of the HEVC video coding process, the range is represented by 9 bits and the row by 10 bits. A renormalization process exists to maintain the range and row values ​​with sufficient precision. Renormalization occurs whenever the range is less than 256. Therefore, after renormalization, the range is always greater than or equal to 256. Depending on the values ​​of the range and row, the binary arithmetic coder (BAC) outputs a bitstream, '0' or '1', or updates an internal variable (referred to as BO (bits-outstanding)) to be retained for future outputs. Figure 8 illustrates examples of BAC outputs based on the range. For instance, when the range and row exceed a specific threshold (e.g., 512), '1' is output to the bitstream. When the range and row are below a specific threshold (e.g., 512), '0' is output to the bitstream. When the range and lower are between specific thresholds, nothing is output to the bitstream. Instead, the BO value is incremented, and the next bin is encoded.

[0175] In the CABAC context model of H.264 / AVC and in some examples of HEVC, there are 128 states. There are 64 possible LPS probabilities (denoted as state σ) that can be 0 to 63. Each MPS can be 0 or 1. Thus, the 128 states are the 64 state probabilities multiplied by two possible values ​​(0 or 1) for the MPS. Therefore, states can be indexed by 7 bits.

[0176] Derived LPS ranges ( rangeLPS σTo reduce computation, results for all cases can be pre-calculated and stored as approximations in a lookup table. Thus, an LPS range can be obtained without arbitrary multiplication by using a simple table lookup. Since this behavior can cause significant latency in many hardware architectures, it may be important to avoid multiplication for some devices or applications.

[0177] A 4-column pre-calculated LPS range table can be used instead of multiplication. The range is divided into 4 segments. The segment index is the query (range >>6)&3 It can be derived by. In practice, the segment index is derived by shifting and dropping bits from the actual range. Table 1 below illustrates the possible ranges and their corresponding indices. Table 1 - Range Index

[0178] Then, the LPS range table has 64 entries (one for each probabilistic state) x 4 (one for each range index). Each entry is the range LPS, that is, the range multiplied by the LPS probability. An example of a portion of this table is shown in Table 2 below. Table 2 shows probabilistic states 9-12. In one proposal for HEVC, probabilistic states can have a range of 0-63. Table 2 - RangeLPS

[0179] In each segment (i.e., range value), each probability state σ The LPS range of is predefined. In other words, the probabilistic state σThe LPS range is quantized into four values ​​(i.e., one value for each range index). The specific LPS range used at a given point depends on which segment the range belongs to. The number of possible LPS ranges used in the table is a trade-off between the number of table columns (i.e., the number of possible LPS range values) and LPS range precision. Generally speaking, more columns result in smaller quantization errors of the LPS range values, but also increase the need for more memory to store the table. Fewer columns result in larger quantization errors, but also reduce the memory required to store the table.

[0180] As explained above, each LPS probability state has a corresponding probability. The probability p for each state is derived as follows: Here, the state σ ranges from 0 to 63. The constant α represents the probability change between each context state. In one example, α=0.9493, or more precisely, is. The probability in the state σ = 0 is 0.5 (i.e., It is equivalent to ). That is, in context state 0, LPS and MPS are equally possible. The probability in each consecutive state is derived by multiplying the previous state by α. Thus, the probability of LPS occurring in context state α = 1 is This is the case. Thus, as the index of state α increases, the probability of LPS occurrence decreases.

[0181] CABAC is adaptive because probabilistic states are updated to follow signal statistics (i.e., the values ​​of previously coded bins). The update process is as follows: For a given probabilistic state, the update relies on the value of the encoded symbol identified as LPS or MPS and the state index. As a result of the update process, a new probabilistic state is derived, consisting of potentially modified LPS probability estimates and, if necessary, modified MPS values.

[0182] If the empty value is equal to the MPS, the given state index can be incremented by 1. This applies to all states except when the MPS occurs at state index 62, where the LPS probability is already at its minimum (or equivalently, reached at the maximum MPS probability). In this case, the state index (62) remains fixed until the LPS is seen or the last empty value is encoded (state 63 is used for the special case of the last empty value). When the LPS occurs, the state index is changed by decreasing the state index by a specific amount, as shown in the formula below. This rule generally applies to each occurrence of the LPS, except for the following: Assuming the LPS is encoded in the state index σ=0, which corresponds to the stochastic equi-probable case, the state index remains fixed, but the MPS value will be toggled so that the LPS and MPS values ​​are interchanged. In all other cases, the MPS value will not change regardless of which symbol is encoded. The derivation of transition rules for LPS probability is given LPS probability p old and its updated counterpart p new It is based on the following relationship between.

[0183] Regarding the practical implementation of the probability estimation process in CABAC, it is important to note that all transition rules can be realized by up to two tables, each having 63 entries of 6-bit unsigned integer values. In some examples, state transitions can be determined by a single table TransIdxLPS, which determines a new updated state index TransIdxLPS [σ] when an LPS is observed for a given state index σ. MPS-driven transitions can be obtained by simple (saturating) increments of the state index by a fixed value of 1, resulting in an updated state index min(σ+1, 62). Table 3 below is an example of a partial TransIdxLPS table. Table 3 - TransIdxLPS

[0184] The techniques described above in connection with FIGS. 7a, 7b, and 8 represent only one exemplary implementation of CABAC. It should be understood that the techniques of this disclosure are not limited to the described implementation of CABAC. For example, in previous BAC approaches (e.g., the BAC approach used in H.264 / AVC), the tables RangeLPS and TransIdxLPS were tuned for low-resolution videos (i.e., CIF (common intermediate format) and QCIF (quarter-CIF) videos). With the use of future codecs such as HEVC and VVC, a large amount of video content is HD (high definition) and, in some cases, higher than HD. Video content with HD or higher resolution tends to have different statistics from the 10-year-old QCIF sequences used to develop H.264 / AVC. Consequently, the tables RangeLPS and TransIdxLPS from H.264 / AVC can cause adaptation between states in a very rapid manner. In other words, the transitions between probabilistic states, particularly when LPS occurs, can be too large for the smoother and higher-resolution content of HD video. Therefore, probabilistic models used according to conventional techniques may not be accurate for HD and extra-HD content. Furthermore, since HD video content contains a wider range of pixel values, H.264 / AVC tables do not include enough entries to account for the more extreme values ​​that may exist in HD content.

[0185] Thus, for HEVC and future coding standards such as VVC, RangeLPS and TransIdxLPS tables can be modified to account for the characteristics of these new contents. In particular, BAC processes for HEVC and future coding standards may use tables that allow for a slower adaptation process and account for more extreme cases (i.e., skewed probabilities). Therefore, as an example, RangeLPS and TransIdxLPS tables can be modified to achieve these goals by including more probabilistic states and ranges than those used in BAC with H.264 / AVC or HEVC.

[0186] FIG. 9 is a block diagram of an exemplary entropy encoding unit (220) that may be configured to perform CABAC according to the techniques of the present disclosure. A syntax element (418) is input to the entropy encoding unit (220). If the syntax element is already a binary-value syntax element (i.e., a syntax element having only values ​​of 0 and 1), the binaryization step may be skipped. If the syntax element is a non-binary value syntax element (e.g., a syntax element represented by a number of bits such as conversion factor levels), the non-binary value syntax element is binaryized by a binaryizer (420). The binaryizer (420) performs the task of mapping the non-binary value syntax element to a sequence of binary decisions. These binary decisions are commonly referred to as "bindles". For example, in the case of transformation factor levels, the level values ​​can be decomposed into consecutive bins, each bin indicating whether the absolute value of the factor level is greater than or equal to some value. For example, bin 0 (sometimes called the importance flag) indicates whether the absolute value of the transformation factor level is greater than 0. Bin 1 indicates whether the absolute value of the transformation factor level is greater than 1, and so on. A unique mapping can be developed for each non-binary value syntax element.

[0187] Each bin generated by the binaryizer (420) is fed to the binary arithmetic coding side of the entropy encoding unit (220). That is, for a predetermined set of non-binary value syntax elements, each bin type (e.g., bin 0) is coded before the next bin type (e.g., bin 1). Coding can be performed in normal mode or bypass mode. In bypass mode, the bypass coding engine (426) performs arithmetic coding using a fixed probability model, for example, Golomb-Rice or exponential Golomb coding. Bypass mode is generally used for more predictable syntax elements.

[0188] Coding in normal mode involves performing CABAC. Normal mode CABAC is intended to code bin values ​​where the probability of a bin value is predictable given the values ​​of previously coded bins. The probability that a bin is LPS is determined by the context modeler (422). The context modeler (422) outputs a bin value and a context model (e.g., a probabilistic state σ). The context model may be an initial context model for a series of bins or may be determined based on the coded values ​​of previously coded bins. As described above, the context modeler may update the state based on whether the previously coded bin is MPS or LPS.

[0189] After the context model and the probabilistic state σ are determined by the context modeler (422), the regular coding engine (424) performs BAC on the bin values. According to the techniques of the present disclosure, the regular coding engine (424) performs BAC using a TransIdxLPS table (430) containing more than 64 probabilistic states σ. In one example, the number of probabilistic states is 128. TransIdxLPS is used to determine which probabilistic state is used for the next bin (bin n+1) when the previous bin (bin n) is an LPS. The regular coding engine (424) may also use a RangeLPS table (128) to determine a range value for an LPS given a specific probabilistic state σ. However, according to the techniques of the present disclosure, rather than using all possible probabilistic states σ of the TransIdxLPS table (430), the probabilistic state indices σ are mapped to indices grouped for use in the RangeLPS table. That is, each index for the RangeLPS table (428) can represent two or more of the total number of probability states. Mapping the probability state index σ to the grouped indices can be linear (e.g., partitioning by 2) or non-linear (e.g., a logarithmic function or a mapping table).

[0190] In other examples of the present disclosure, the difference between continuous probabilistic states may be made smaller by setting the parameter α to be greater than 0.9493. In one example, α = 0.9689. In another example of the present disclosure, the maximum probability (p0) of an LPS occurrence may be set lower than 0.5. In one example, p0 may be equal to 0.493.

[0191] In contrast to using the same value of a variable (e.g., window size, scaling factor (α), and one or more of the probability update rate) used to update a probability state in a binary arithmetic coding process, according to one or more techniques of the present disclosure, the entropy encoding unit (220) may use different variable values ​​for different context models and / or different syntax elements. For example, the entropy encoding unit (220) may determine the value of a variable used to update a probability state in a binary arithmetic coding process for a context model of a plurality of context models, and may update the probability state based on the determined value.

[0192] FIG. 10 is a block diagram of an exemplary entropy decoding unit (302) that may be configured to perform CABAC according to the techniques of the present disclosure. The entropy decoding unit (302) of FIG. 10 performs CABAC inversely to the method of the entropy encoding unit (220) described in FIG. 9. Coded bits from a bitstream (448) are input to the entropy decoding unit (302). The coded bits are fed to a context modeler (450) or a bypass decoding engine (452) based on whether the coded bits were entropy coded using bypass mode or normal mode. If the coded bits were coded in bypass mode, the bypass decoding engine (452) may retrieve bins of non-binary syntax elements or binary-value syntax elements using, for example, Golomb-Rice or exponential Golomb decoding.

[0193] If the coded bits are coded in a normal mode, the context modeler (450) can determine a probabilistic model for the coded bits, and the normal decoding engine (454) can decode the coded bits to generate bins of non-binary value syntax elements (or the syntax elements themselves if they are binary values). After the context model and the probabilistic state σ are determined by the context modeler (450), the normal decoding engine (454) performs BAC on the bin values. According to the techniques of the present disclosure, the normal decoding engine (454) performs BAC using a TransIdxLPS table (458) containing more than 64 probabilistic states σ. In one example, the number of probabilistic states is 128, but other numbers of probabilistic states may be defined in accordance with the techniques of the present disclosure. The TransIdxLPS table (458) is used to determine which probability state is used for the next bin (bin n+1) when the previous bin (bin n) is an LPS. The normalized decoding engine (454) may also use the RangeLPS table (456) to determine a range value for an LPS given a specific probability state σ. However, according to the techniques of the present disclosure, rather than using all possible probability states σ of the TransIdxLPS table (458), probability state indices σ are mapped to grouped indices for use in the RangeLPS table (456). That is, each index for the RangeLPS table (456) can represent two or more of the total number of probability states. Mapping probability state indices σ to grouped indices may be linear (e.g., partitioning by 2) or non-linear (e.g., a logarithmic function or a mapping table).

[0194] In other examples of the present disclosure, the difference between continuous probabilistic states may be made smaller by setting the parameter α to be greater than 0.9493. In one example, α = 0.9689. In yet another example of the present disclosure, the maximum probability (p0) of an LPS occurrence may be set lower than 0.5. In one example, p0 may be equal to 0.493.

[0195] After the beans are decoded by the regular decoding engine (454), the binarizer (460) can perform reverse mapping to convert the beans back into values ​​of non-binary value syntax elements.

[0196] FIG. 11 is a flowchart illustrating an exemplary operation of a video encoder for encoding a current block of video data. The current block may include a current CU. Although described in relation to the video encoder (200) (Figs. 1 and 5), it should be understood that other devices may be configured to perform an operation similar to that of FIG. 11.

[0197] In this example, the video encoder (200) initially predicts the current block (550). For example, the video encoder (200) can form a predicted block for the current block. Then, the video encoder (200) can calculate a residual block for the current block (552). To calculate the residual block, the video encoder (200) can calculate the difference between the original uncoded block and the predicted block for the current block. Then, the video encoder (200) can transform and quantize the coefficients of the residual block (554). Next, the video encoder (200) can scan the quantized transform coefficients of the residual block (556). During or after the scan, the video encoder (200) can entropy-encode the transform coefficients (558). For example, the video encoder (200) can encode the transform coefficients using CAVLC or CABAC. Then, the video encoder (200) can output the entropy-coded data of the block (560).

[0198] FIG. 12 is a flowchart illustrating an exemplary operation of a video decoder for decoding a current block of video data. The current block may include a current CU. Although described in relation to the video decoder (300) (Fig. 1 and Fig. 6), it should be understood that other devices may be configured to perform an operation similar to that of FIG. 12.

[0199] The video decoder (300) can receive entropy-coded data for the current block, such as entropy-coded data and entropy-coded prediction information for the coefficients of the residual block corresponding to the current block (570). The video decoder (300) can entropy-decode the entropy-coded data to determine prediction information for the current block and to regenerate the coefficients of the residual block (572). The video decoder (300) can predict the current block using an intra-prediction or inter-prediction mode, such as indicated by the prediction information for the current block, to calculate the prediction block for the current block (574). Then, the video decoder (300) can back-scan the regenerated coefficients to generate a block of quantized transformation coefficients (576). Then, the video decoder (300) can inverse-quantize and inverse-transform the transformation coefficients to generate a residual block (578). The video decoder (300) can ultimately decode the current block by combining the prediction block and the residual block (580).

[0200] FIG. 13 is a flowchart illustrating an exemplary operation of a video encoder for encoding a current block of video data. The current block may be, for example, a conversion unit or a conversion block. Although described in relation to a video encoder (200) (Figs. 1 and 5), it should be understood that other devices may be configured to perform an operation similar to that of FIG. 13.

[0201] In the example of FIG. 13, the video encoder (200) determines values ​​for the coefficients of a group of transform coefficients (602) and context-encodes the syntax elements for a first set of coefficients of a group of transform coefficients until a maximum number of normally coded bins is reached (604). The context-encoded syntax elements include one or more significance flags indicating whether the absolute level for the transform coefficient is equal to 0, one or more parity level flags indicating whether the transform coefficient has an even or odd absolute level, and one or more first flags indicating whether the transform coefficient has an absolute level greater than 2. To context-encode the syntax elements of a group of transform coefficients, the video encoder (200) may be configured to perform context-adaptive binary arithmetic encoding to encode the syntax elements of a group of transform coefficients. The video encoder (200) bypass-encodes additional syntax elements for a second set of coefficients of a group of transformation coefficients in response to reaching a maximum number of normally coded bins (606).

[0202] FIG. 14 is a flowchart illustrating an exemplary operation of a video encoder for bypass encoding additional syntax elements for a second set of coefficients in a group of transform coefficients. In this regard, FIG. 14 illustrates an exemplary process that may correspond to block (606) of FIG. 13. In the example of FIG. 14, the video encoder (200) determines a level value for the transform coefficients of the second set of coefficients (608). The video encoder (200) determines whether the level value for the transform coefficients is smaller than a threshold value (610). If the transform coefficients are smaller than the threshold value (610), the video encoder (200) encodes a prefix value equal to the transform coefficient level using Golomb-Rice coding (612). Thus, the video encoder (200) encodes the level for the transform coefficients that is smaller than the threshold value without encoding the suffix value for the transform coefficients.

[0203] If the conversion factor is greater than the threshold value (610, no), the video encoder (200) encodes a prefix value equal to the threshold value using Golomb-Rice coding (614) and encodes a suffix value using exponential Golomb coding (616). The video encoder (200) may determine the suffix value, for example, by subtracting the prefix value from the level value for the conversion factor. The level value for the conversion factor may be an absolute level value or a remainder level value.

[0204] FIG. 15 is a flowchart illustrating an exemplary operation of a video decoder for decoding a current block of video data. The current block may be, for example, a conversion unit or a conversion block. Although described in relation to the video decoder (300) (Figs. 1 and 6), it should be understood that other devices may be configured to perform an operation similar to that of FIG. 14.

[0205] In the example of FIG. 15, the video decoder (300) context-decodes syntax elements for a first set of coefficients in a group of transform coefficients until it reaches a maximum number of normally coded bins (620). The context-encoded syntax elements include one or more significance flags indicating whether the absolute level for the transform coefficient is equal to 0, one or more parity level flags indicating whether the transform coefficient has an even or odd absolute level, and one or more first flags indicating whether the transform coefficient has an absolute level greater than 2. To context-decode the syntax elements of the group of transform coefficients, the video decoder may be configured to perform context-adaptive binary arithmetic decoding to decode the syntax elements of the group of transform coefficients.

[0206] The video decoder (300) bypass decodes additional syntax elements for a second set of coefficients in response to reaching a maximum number of normally coded bins (622). The video decoder (300) determines values ​​for a first set of coefficients of a transform unit based on context-decoded syntax elements (624), and determines values ​​for a second set of coefficients of a transform unit based on additional syntax elements (626). The video decoder (300) determines a decoded transform block based on the values ​​for the first set of coefficients and the values ​​for the second set of coefficients (628).

[0207] FIG. 16 is a flowchart illustrating an exemplary operation of a video decoder for bypass decoding additional syntax elements for a second set of coefficients in a group of transform coefficients. In this regard, FIG. 16 illustrates an exemplary process that may correspond to block (622) of FIG. 15. In the example of FIG. 14, the video decoder (300) receives a prefix value for a transform coefficient (630) and decodes the prefix value using Golomb-Rice coding (632). The video decoder (300) determines whether the decoded prefix value is smaller than a threshold value (634). If the decoded prefix value is smaller than the threshold value (634, yes), the video decoder (300) determines that the transform coefficient level is the same as the decoded prefix value. In this case, the video decoder (300) determines the level value for the transform coefficient without receiving a suffix value.

[0208] If the decoded prefix value is greater than the threshold value (634, no), the video decoder (300) receives the suffix value for the transform factor (638) and decodes the suffix value using exponential Golomb coding (640). The video decoder (300) determines that the level for the transform factor is equal to the sum of the decoded prefix value and the decoded suffix value (642).

[0209] It will be recognized that, depending on the example, specific acts or events of any of the techniques described herein may be performed in different sequences, added, merged, or all excluded (e.g., not all described acts or events are necessary for the implementation of the techniques). Furthermore, in certain examples, acts or events may be performed simultaneously rather than sequentially, for example, through multi-threaded processing, interrupt processing, or multiple processors.

[0210] In one or more examples, the described functions may be implemented in hardware, software, firmware, or any combination thereof. Where implemented in software, the functions may be stored on or transmitted through a computer-readable medium as one or more instructions or code, and may be executed by a hardware-based processing unit. Computer-readable media may include computer-readable storage media corresponding to media of the same type as data storage media, or communication media including any medium that enables the transmission of a computer program from one place to another according to a communication protocol, for example. In this way, computer-readable media may generally correspond to (1) non-transient types of computer-readable storage media, or (2) communication media such as signals or carrier waves. Data storage media may be any available media that can be accessed by one or more computers or one or more processors to retrieve instructions, code and / or data structures for the implementation of the techniques described in this disclosure. A computer program product may include a computer-readable medium.

[0211] As an example, not a limitation, such computer-readable storage media may include one or more of RAM, ROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage, or other magnetic storage devices, flash memory, or any other media that can be used to store desired program code in the form of instructions or data structures and can be accessed by a computer. Additionally, any connection is appropriately referred to as a computer-readable medium. For example, if instructions are transmitted from a website, server, or other remote source using coaxial cable, fiber optic cable, twisted pair, DSL (digital subscriber line), or wireless technologies (such as infrared, radio, and microwave), coaxial cable, fiber optic cable, twisted pair, DSL, or wireless technologies (such as infrared, radio, and microwave) are included within the definition of the medium. However, it should be understood that computer-readable storage media and data storage media do not include connections, carriers, signals, or other transient media, but instead relate to non-transient types of storage media. The disks and discs used herein include CDs (compact discs), laser discs (discs), optical discs (discs), DVDs (digital versatile discs), floppy disks (discs), and Blu-ray discs (discs), wherein disks typically reproduce data magnetically, whereas discs reproduce data optically using lasers. Combinations of the above should also be included within the scope of computer-readable media.

[0212] Instructions may be executed by one or more processors, such as one or more DSPs, general-purpose microprocessors, ASICs, FPGAs, or other equivalent integrated or discrete logic networks. Accordingly, the term “processor” as used herein may refer to any of the previously described structures or any other structures suitable for the implementation of the techniques described herein. Additionally, in some aspects, the functions described herein may be provided within dedicated hardware and / or software modules configured for encoding and decoding, or may be included within a combined codec. Furthermore, the techniques may be fully implemented with one or more circuits or logic elements.

[0213] The techniques of the present disclosure may be implemented in a wide variety of devices or apparatuses, including wireless handsets, integrated circuits (ICs), or sets of ICs (e.g., chipsets). Various components, modules, or units are described in the present disclosure to highlight the functional aspects of devices configured to perform the disclosed techniques, but implementation by different hardware units is not required. Rather, as described above, various units may be combined in a codec hardware unit or provided by a collection of interactive hardware units including one or more processors as described above, together with suitable software and / or firmware.

[0214] Various examples have been described. These and other examples are within the scope of the following claims.

Claims

Claim 1 A method for decoding video data, comprising the step of context-decoding syntax elements for a first set of coefficients of a group of transform coefficients until a maximum number of normally coded bins is reached — said context-decoded syntax elements include one or more significance flags, one or more parity level flags, and one or more first flags, wherein each of said one or more significance flags indicates whether the absolute level of the transform coefficient is equal to 0, each of said one or more parity level flags indicates whether the transform coefficient has an even or odd absolute level, and each of said one or more first flags indicates whether the transform coefficient has an absolute level greater than 2 —; and the step of bypass-decoding additional syntax elements for a second set of coefficients in response to reaching said maximum number of normally coded bins — said bypass-decoding additional syntax elements comprises: receiving a prefix value for a level value of the transform coefficient of said second set of coefficients The method comprises: decoding the prefix value using Golomb-Rice coding; receiving a suffix value for a level value of the transformation coefficient in response to the length of the prefix value being equal to a threshold length; and decoding the suffix value using exponential Golomb coding, wherein the threshold length is a fixed value for all transformation coefficients of the second set of coefficients; and determining level values ​​for the first set of coefficients of the transformation unit based on the context-decoded syntax elements.A method for decoding video data, comprising the step of determining level values ​​for the second set of coefficients of the conversion unit based on the additional syntax elements, wherein the step of determining level values ​​for the second set of coefficients of the conversion unit based on the additional syntax elements includes the step of determining level values ​​of the conversion coefficients based on the decoded prefix value and the decoded suffix value. Claim 2 A method for decoding video data according to claim 1, wherein determining the level value of the conversion coefficient comprises: adding the decoded prefix value to the decoded suffix value. Claim 3 A method for decoding video data according to claim 1, wherein bypass decoding the additional syntax elements comprises: receiving a second prefix value for a level value of a second coefficient of the second set of coefficients; decoding the second prefix value using Golomb-Rice coding; and determining the level value of the second coefficient without receiving a suffix value for a level value of the second coefficient in response to the length of the second prefix value being smaller than the threshold length. Claim 4 A method for decoding video data according to claim 1, wherein bypass decoding the additional syntax elements further comprises: determining a value for a Rice parameter for the transform coefficient; and determining a threshold length based on the value for the Rice parameter. Claim 5 A method for decoding video data according to claim 1, wherein context decoding of syntax elements of the transform factor group comprises performing context-adaptive binary arithmetic decoding to decode the syntax elements of the transform factor group. Claim 6 A method for decoding video data according to claim 1, wherein the level value of the conversion coefficient includes an absolute level value. Claim 7 A method for decoding video data according to claim 1, wherein the level value of the conversion coefficient includes the remaining level value. Claim 8 A method for decoding video data according to claim 1, wherein the threshold length is equal to 5. Claim 9 A method for decoding video data according to claim 1, wherein the threshold length is the same as 6. Claim 10 A method for decoding video data according to claim 1, further comprising: determining a decoded transform block based on level values ​​for coefficients of a first set and level values ​​for coefficients of a second set; adding the decoded transform block to a prediction block to determine a reconstructed block; performing one or more filtering operations on the reconstructed block to determine a decoded video data block; and outputting a decoded video data picture including the decoded video data block. Claim 11 A device for decoding video data comprising: a memory configured to store video data; and one or more processors implemented as a circuitry, wherein the one or more processors: context-decode syntax elements for a first set of coefficients of a group of transform coefficients until a maximum number of normally coded bins are reached — the context-decoded syntax elements comprise one or more importance flags, one or more parity level flags, and one or more first flags, wherein each of the one or more importance flags indicates whether the absolute level for the transform coefficient is equal to 0, each of the one or more parity level flags indicates whether the transform coefficient has an even or odd absolute level, and each of the one or more first flags indicates whether the transform coefficient has an absolute level greater than 2 —; In response to reaching the maximum number of normally coded bins, additional syntax elements for a second set of coefficients are bypass decoded — and to bypass decode the additional syntax elements, the one or more processors are configured to: receive a prefix value for a level value of a transformation coefficient of the second set of coefficients; decode the prefix value using Golomb-Rice coding; receive a suffix value for a level value of the transformation coefficient in response to the length of the prefix value being equal to a threshold length; and decode the suffix value using exponential Golomb coding, wherein the threshold length is a fixed value for all transformation coefficients of the second set of coefficients —; determine level values ​​for the first set of coefficients of the transformation unit based on the context-decoded syntax elements;A device for decoding video data, configured to determine level values ​​for the second set of coefficients of the conversion unit based on the additional syntax elements, and configured such that, in order to determine level values ​​for the second set of coefficients of the conversion unit based on the additional syntax elements, the one or more processors are configured to determine level values ​​of the conversion coefficients based on the decoded prefix value and the decoded suffix value. Claim 12 A device for decoding video data, wherein, in order to determine the level value of the conversion coefficient, the one or more processors are configured to add the decoded prefix value to the decoded suffix value. Claim 13 A device for decoding video data according to claim 11, wherein, for bypass decoding the additional syntax elements, the one or more processors are configured to: receive a second prefix value for a second coefficient of the second set of coefficients; decode the second prefix value using Golomb-Rice coding; and, in response to the length of the second prefix value being less than the threshold length, determine a level value of the second coefficient without receiving a suffix value for the second coefficient. Claim 14 A device for decoding video data, wherein, in order to bypass decode the additional syntax elements, the one or more processors are configured to: determine a value for a Rice parameter for the transform coefficient; and determine a threshold length based on the value for the Rice parameter. Claim 15 A device for decoding video data according to claim 11, wherein, in order to context decode the syntax elements of the transform factor group, the one or more processors are configured to perform context-adaptive binary arithmetic decoding to decode the syntax elements of the transform factor group. Claim 16 A device for decoding video data according to claim 11, wherein the level value of the conversion coefficient includes an absolute level value. Claim 17 A device for decoding video data, wherein the level value of the conversion coefficient includes the remaining level value in claim 11. Claim 18 A device for decoding video data, wherein the threshold length is the same as 5 in claim 11. Claim 19 A device for decoding video data, wherein, in claim 11, the threshold length is the same as 6. Claim 20 A device for decoding video data, wherein, in claim 11, the one or more processors are configured to: determine a decoded transform block based on level values ​​for the first set of coefficients and level values ​​for the second set of coefficients; add the decoded transform block to a prediction block to determine a restored block; perform one or more filtering operations on the restored block to determine a decoded video data block; and output a decoded video data picture including the decoded video data block. Claim 21 A method for encoding video data comprises: determining level values ​​for coefficients of a group of transform coefficients; context encoding syntax elements for a first set of coefficients of the group of transform coefficients until a maximum number of normally coded bins is reached — the context encoded syntax elements include one or more importance flags, one or more parity level flags, and one or more first flags, wherein each of the one or more importance flags indicates whether the absolute level of the transform coefficient is equal to 0, each of the one or more parity level flags indicates whether the transform coefficient has an even or odd absolute level, and each of the one or more first flags indicates whether the transform coefficient has an absolute level greater than 2 —; and bypass encoding additional syntax elements for a second set of coefficients of the group of transform coefficients in response to reaching the maximum number of normally coded bins, wherein bypass encoding the additional syntax elements comprises: determining level values ​​of the transform coefficients of the second set of coefficients; A method for encoding video data, comprising: encoding a prefix value for the level value of the transform factor using Golomb-Rice coding in response to the level value of the transform factor being greater than a threshold length—wherein the threshold length is a fixed value for all transform factors of the second set of factors—; and encoding a suffix value for the level value of the transform factor using exponential Golomb coding in response to the level value being greater than the threshold length. Claim 22 A method for encoding video data according to claim 21, further comprising the step of determining the suffix value by subtracting the prefix value from the level value of the conversion coefficient. Claim 23 A method for encoding video data according to claim 21, wherein bypass encoding the additional syntax elements comprises: determining a second level value for a second coefficient of the second set of coefficients; and, in response to the second level value being smaller than the threshold length, encoding a prefix value for the second coefficient using Golomb-Rice coding without encoding a suffix value for the second coefficient. Claim 24 A method for encoding video data according to claim 21, wherein bypass encoding the additional syntax elements further comprises: determining a value for a Rice parameter for the transform coefficient; and determining a threshold length based on the value for the Rice parameter. Claim 25 A method for encoding video data according to claim 21, wherein context encoding the syntax elements of the transform factor group comprises performing context-adaptive binary arithmetic encoding to encode the syntax elements of the transform factor group. Claim 26 A method for encoding video data in claim 21, wherein the level value of the conversion coefficient includes an absolute level value. Claim 27 A method for encoding video data in claim 21, wherein the level value of the conversion coefficient includes the remaining level value. Claim 28 A method for encoding video data according to claim 21, wherein the threshold length is equal to 5. Claim 29 A method for encoding video data according to claim 21, wherein the threshold length is the same as 6. Claim 30 A device for encoding video data, comprising: a memory configured to store video data; and one or more processors implemented as a circuit network, wherein the one or more processors: determine level values ​​for coefficients of a group of transform coefficients; and context-encode syntax elements for a first set of coefficients of the group of transform coefficients until a maximum number of normally coded bins are reached — the context-encoded syntax elements include one or more importance flags, one or more parity level flags, and one or more first flags, wherein each of the one or more importance flags indicates whether the absolute level for the transform coefficient is equal to 0, each of the one or more parity level flags indicates whether the transform coefficient has an even or odd absolute level, and each of the one or more first flags indicates whether the transform coefficient has an absolute level greater than 2 —; A device for encoding video data, configured to bypass encode additional syntax elements for a second set of coefficients of the transform coefficient group in response to reaching the maximum number of normally coded bins, wherein bypass encoding the additional syntax elements comprises: determining a level value of the transform coefficient of the second set of coefficients; encoding a prefix value for the level value of the transform coefficient using Golomb-Rice coding in response to the level value of the transform coefficient being greater than a threshold length — the threshold length being a fixed value for all transform coefficients of the second set of coefficients —; and encoding a suffix value for the level value of the transform coefficient using exponential Golomb coding in response to the level value being greater than the threshold length. Claim 31 A device for encoding video data, wherein, in claim 30, the one or more processors are additionally configured to determine the suffix value by subtracting the prefix value from the level value of the conversion factor. Claim 32 A device for encoding video data, wherein, in order to bypass encoding the additional syntax elements of claim 30, the one or more processors are further configured to: determine a second level value for a second coefficient of the second set of coefficients; and, in response to the second level value being smaller than the threshold length, to encode a prefix value for the second coefficient using Golomb-Rice coding without encoding a suffix value for the second coefficient. Claim 33 A device for encoding video data, wherein, in order to bypass-encode the additional syntax elements, the one or more processors are further configured to: determine a value for a Rice parameter for the transform factor; and determine the threshold length based on the value for the Rice parameter. Claim 34 A device for encoding video data according to claim 30, wherein, for context encoding the syntax elements of the transform factor group, the one or more processors are configured to perform context-adaptive binary arithmetic encoding to encode the syntax elements of the transform factor group. Claim 35 A device for encoding video data, wherein, in claim 30, the level value of the conversion coefficient includes an absolute level value. Claim 36 A device for encoding video data, wherein, in claim 30, the level value of the conversion coefficient includes the remaining level value. Claim 37 In claim 30, a device for encoding video data, wherein the threshold length is the same as 5. Claim 38 A device for encoding video data, wherein, in claim 30, the threshold length is the same as 6. Claim 39 As a non-transient computer-readable storage medium for storing instructions, said instructions, when executed by one or more processors, cause said one or more processors: to context-decode syntax elements for a first set of coefficients of a group of transformation coefficients until reaching a maximum number of normally coded bins — said context-decoded syntax elements include one or more importance flags, one or more parity level flags, and one or more first flags, wherein each of said one or more importance flags indicates whether the absolute level for the transformation coefficient is equal to 0, each of said one or more parity level flags indicates whether the transformation coefficient has an even or odd absolute level, and each of said one or more first flags indicates whether the transformation coefficient has an absolute level greater than 2 —; to bypass-decode additional syntax elements for a second set of coefficients in response to reaching the maximum number of normally coded bins — and to bypass-decode said additional syntax elements, said instructions One or more processors are to: receive a prefix value for a level value of a transformation coefficient of the second set of coefficients; decode the prefix value using Golomb-Rice coding; receive a suffix value for a level value of the transformation coefficient in response to the length of the prefix value being equal to a threshold length; and decode the suffix value using exponential Golomb coding, wherein the threshold length is a fixed value for all transformation coefficients of the second set of coefficients—; determine level values ​​for the first set of coefficients of the transformation unit based on the context-decoded syntax elements;A non-transient computer-readable storage medium comprising determining level values ​​for the second set of coefficients of the conversion unit based on the additional syntax elements, and determining level values ​​for the second set of coefficients of the conversion unit based on the additional syntax elements, wherein the level values ​​of the conversion coefficients are determined based on the decoded prefix value and the decoded suffix value. Claim 40 A device for decoding video data, comprising: means for context-decoding syntax elements for a first set of coefficients of a group of transform coefficients until reaching a maximum number of normally coded bins ― said context-decoded syntax elements include one or more importance flags, one or more parity level flags, and one or more first flags, wherein each of said one or more importance flags indicates whether the absolute level for the transform coefficient is equal to 0, each of said one or more parity level flags indicates whether the transform coefficient has an absolute level that is even or odd, and each of said one or more first flags indicates whether the transform coefficient has an absolute level greater than 2 ―; means for bypass-decoding additional syntax elements for a second set of coefficients in response to reaching the maximum number of normally coded bins ― said means for bypass-decoding additional syntax elements comprises: means for receiving a prefix value for a level value of the transform coefficient of said second set of coefficients; Means for decoding the prefix value using Golomb-Rice coding; means for receiving a suffix value for a level value of the transformation coefficient in response to the length of the prefix value being equal to a threshold length; and means for decoding the suffix value using exponential Golomb coding, wherein the threshold length is a fixed value for all transformation coefficients of the second set of coefficients; and means for determining level values ​​for the first set of coefficients of the transformation unit based on the context-decoded syntax elements;An apparatus for decoding video data, comprising means for determining level values ​​for the second set of coefficients of the conversion unit based on the additional syntax elements, wherein determining level values ​​for the second set of coefficients of the conversion unit based on the additional syntax elements includes determining level values ​​of the conversion coefficients based on the decoded prefix value and the decoded suffix value. Claim 41 delete Claim 42 delete Claim 43 delete Claim 44 delete

Images