Low-Complexity History Use for Rice Parameter Derivation in High-Bit-Depth Video Coding

Abstract

Techniques for processing video data using history-based Rice parameter derivation are described herein. For example, the process may include obtaining a transform block including a plurality of samples. One or more parameters (e.g., Rice parameters) for the plurality of samples may be determined by analyzing a local neighborhood of a current sample among the plurality of samples and determining that a number of neighboring transform coefficients of the current sample is less than a threshold amount. Historical parameter values ​​(e.g., historical Rice parameter values) determined from one or more previously decoded transform blocks may be obtained, and parameters (e.g., Rice parameters) for the current sample may be determined based at least in part on the historical parameter values. The current sample may be decoded based on the determined parameters of the current sample.

Description

[Technical Field]

[0001]

[0001] This application relates to video coding (e.g., video encoding and / or video decoding). For example, aspects of this application relate to systems and techniques for improving parameter derivation (e.g., Rice parameter derivation) for regular residual coding (RRC) in high bit-depth coding. The systems and techniques are applicable to new extensions of the generic video coding (VVC) standard, among other standards and extensions thereof. [Background technology]

[0002]

[0002] Many devices and systems enable video data to be processed and output for consumption. Digital video data comprises a large amount of data to meet the demands of consumers and video providers. For example, consumers of video data desire the highest quality video, with high fidelity, resolution, frame rates, etc. As a result, the large amount of video data required to meet these demands places a strain on communication networks and devices that process and store the video data.

[0003]

[0003] Various video coding techniques can be used to compress video data. Video coding is performed according to one or more video coding standards. For example, video coding standards include, among others, Generic Video Coding (VVC), High Efficiency Video Coding (HEVC), Advanced Video Coding (AVC), MPEG-2 Part 2 coding (MPEG stands for moving picture experts group), as well as proprietary video codecs / formats such as AOMedia Video 1 (AV1) developed by the Alliance for Open Media. Video coding generally utilizes prediction methods (e.g., inter-prediction, intra-prediction, etc.) that exploit redundancy present in a video image or sequence. The goal of video coding techniques is to compress video data into a format that uses a lower bitrate while avoiding or minimizing degradation to video quality. As ever-evolving video services become available, encoding techniques with better coding efficiency are needed. Summary of the Invention

[0004] In some examples, systems and techniques for parameter derivation (e.g., Rice parameter derivation) based at least in part on historical parameter information (e.g., historical Rice parameter information) are described. According to at least one illustrative example, a method for decoding video data is provided. The method includes obtaining a transform block, the transform block including a plurality of samples; determining one or more parameters for the plurality of samples at least in part by analyzing a local neighborhood of a current sample among the plurality of samples; determining, based at least in part on the analysis of the local neighborhood, that a number of neighboring transform coefficients of the current sample is less than a threshold amount; obtaining historical parameter values ​​determined from one or more previously decoded transform blocks; determining parameters for the current sample based at least in part on the historical parameter values; and decoding the current sample based on the determined parameters for the current sample.

[0005] In another example, an apparatus for decoding video data is provided, the apparatus including a memory and one or more processors coupled to the memory (e.g., implemented in a circuit). The one or more processors are configured to: obtain a transform block, the transform block including a plurality of samples; determine one or more parameters for the plurality of samples at least in part by analyzing a local neighborhood of a current sample among the plurality of samples; determine that a number of neighboring transform coefficients of the current sample is less than a threshold amount based at least in part on the analysis of the local neighborhood; obtain historical parameter values ​​determined from one or more previously decoded transform blocks; determine parameters for the current sample based at least in part on the historical parameter values; and decode the current sample based on the determined parameters for the current sample.

[0006]

[0006] In another example, a non-transitory computer-readable medium is provided having stored thereon instructions that, when executed by one or more processors, cause the one or more processors to: obtain a transform block, the transform block including a plurality of samples; determine one or more parameters for the plurality of samples at least in part by analyzing a local neighborhood of a current sample among the plurality of samples; determine, based at least in part on the analysis of the local neighborhood, that a number of neighboring transform coefficients of the current sample is less than a threshold amount; obtain historical parameter values ​​determined from one or more previously decoded transform blocks; determine parameters for the current sample based at least in part on the historical parameter values; and decode the current sample based on the determined parameters of the current sample.

[0007]

[0007] In another example, an apparatus is provided, the apparatus including: means for obtaining a transform block, the transform block including a plurality of samples; means for determining one or more parameters for the plurality of samples at least in part by analyzing a local neighborhood of a current sample among the plurality of samples; means for determining, based at least in part on the analysis of the local neighborhood, that a number of neighboring transform coefficients of the current sample is less than a threshold amount; means for obtaining historical parameter values ​​determined from one or more previously decoded transform blocks; means for determining parameters of the current sample based at least in part on the historical parameter values; and means for decoding the current sample based on the determined parameters of the current sample.

[0008]

[0008] In another example, a method for encoding video data is provided, the method including: obtaining a transform block, the transform block including a plurality of samples; determining one or more parameters for the plurality of samples at least in part by analyzing a local neighborhood of a current sample among the plurality of samples; determining, based at least in part on the analysis of the local neighborhood, that a number of neighboring transform coefficients of the current sample is less than a threshold amount; obtaining historical parameter values ​​determined from one or more previously coded transform blocks; determining parameters for the current sample based at least in part on the historical parameter values; and generating a bitstream based on the determined parameters for the current sample.

[0009] In another example, an apparatus for encoding video data is provided, the apparatus including a memory and one or more processors coupled to the memory (e.g., implemented in a circuit). The one or more processors are configured to: obtain a transform block, the transform block including a plurality of samples; determine one or more parameters for the plurality of samples at least in part by analyzing a local neighborhood of a current sample of the plurality of samples; determine that a number of neighboring transform coefficients of the current sample is less than a threshold amount based at least in part on the analysis of the local neighborhood; obtain historical parameter values ​​determined from one or more previously coded transform blocks; determine parameters for the current sample based at least in part on the historical parameter values; and generate a bitstream based on the determined parameters for the current sample.

[0010]

[0010] In another example, a non-transitory computer-readable medium is provided having stored thereon instructions that, when executed by one or more processors, cause the one or more processors to: obtain a transform block, the transform block including a plurality of samples; determine one or more parameters for the plurality of samples at least in part by analyzing a local neighborhood of a current sample among the plurality of samples; determine, based at least in part on the analysis of the local neighborhood, that a number of neighboring transform coefficients of the current sample is less than a threshold amount; obtain historical parameter values ​​determined from one or more previously decoded transform blocks; determine parameters for the current sample based at least in part on the historical parameter values; and generate a bitstream based on the determined parameters of the current sample.

[0011]

[0011] In another example, an apparatus is provided, the apparatus including: means for obtaining a transform block, the transform block including a plurality of samples; means for determining one or more parameters for the plurality of samples at least in part by analyzing a local neighborhood of a current sample among the plurality of samples; means for determining, based at least in part on the analysis of the local neighborhood, that a number of neighboring transform coefficients of the current sample is less than a threshold amount; means for obtaining historical parameter values ​​determined from one or more previously coded transform blocks; means for determining parameters for the current sample based at least in part on the historical parameter values; and means for generating a bitstream based on the determined parameters of the current sample.

[0012] In some aspects, the one or more parameters for the plurality of samples include one or more Rice parameters, the historical parameter values ​​are historical Rice parameter values, and the parameters determined for the current sample are Rice parameters of the current sample. In some aspects, the existing historical parameter values ​​are existing historical Rice parameter values.

[0013]

[0013] In some aspects, the methods, apparatus, and computer-readable media described above further comprise determining a parameter of the current sample based on a first integer multiple of the historical parameter value, based at least in part on a determination that the number of neighboring transform coefficients is 0.

[0014]

[0014] In some aspects, determining the parameter of the current sample comprises providing a first integer multiple of the historical parameter value as an input to a lookup table that maps between inputs and parameters.

[0015] In some aspects, the first integer multiple and the threshold amount are the same value.

[0016]

[0016] In some aspects, the methods, devices, and computer-readable media described above further comprise determining a parameter for the current sample based on a second integer multiple of the historical parameter value and the sum of the neighboring transform coefficients, based at least in part on a determination that the number of neighboring transform coefficients is greater than 0.

[0017]

[0017] In some aspects, determining the parameters of the current sample comprises providing the sum of the neighboring transform coefficients and a second integer multiple of the summed historical parameter value as an input to a lookup table that maps between inputs and parameters.

[0018] In some aspects, the second integer multiple is smaller than the first integer multiple.

[0019]

[0019] In some aspects, determining that the number of neighboring transform coefficients is less than a threshold amount is based at least in part on identifying one or more unavailable neighboring transform coefficients for the current sample.

[0020]

[0020] In some aspects, the methods, apparatus, and computer-readable media described above further comprise obtaining a location of a current sample within a transform block; comparing the location of the current sample to one or more of a width of the transform block and a height of the transform block; and identifying one or more unavailable neighboring transform coefficients based at least in part on the comparison.

[0021] In some aspects, the one or more unavailable neighboring transform coefficients are associated with locations outside the transform block.

[0022]

[0022] In some aspects, determining that the number of neighboring transform coefficients is less than a threshold amount comprises determining that a horizontal component of the current sample location is within a first distance of the width of the transform block; and determining that a vertical component of the current sample location is within a second distance of the height of the transform block.

[0023] In some aspects, the plurality of samples are associated with a transform block sample type, the transform block sample type including luma samples or chroma samples.

[0024] In some aspects, the transform block sample type is the same as the sample type associated with one or more previously decoded transform blocks from which the historical parameter values ​​are determined.

[0025]

[0025] In some aspects, the history parameter value is determined based at least in part on the first non-zero decoded transform coefficient obtained from each of one or more previously decoded transform blocks.

[0026]

[0026] In some aspects, the methods, apparatus, and computer-readable media described above further comprise determining a binary code length of each first non-zero decoded transform coefficient obtained from each of one or more previously decoded transform blocks.

[0027]

[0027] In some aspects, the history parameter value is determined as an exponentially weighted moving average of binary code lengths determined for the first non-zero decoded transform coefficient of each of one or more previously decoded transform blocks.

[0028]

[0028] In some aspects, decoding the current sample based on the determined parameters of the current sample comprises decoding a syntax element indicating the current sample based on the determined parameters.

[0029] In some aspects, decoding the current sample based on the determined parameters comprises decoding a Golomb-Rice code using the determined parameters.

[0030]

[0030] In another example, a method for decoding video data is provided, the method including: obtaining a transform block; determining one or more non-zero decoded transform coefficients based at least in part on an analysis of the transform block; determining a history update value for the transform block based at least in part on the one or more non-zero decoded transform coefficients; updating an existing history parameter value at least in part by combining the history update value for the transform block with an existing history parameter value, the existing history parameter value being based at least in part on a series of non-zero decoded transform coefficients determined from a series of previously analyzed transform blocks; and decoding at least one sample of the transform block based on the existing history parameter value or the updated existing history parameter value.

[0031] In another example, an apparatus for decoding video data is provided, the apparatus including a memory and one or more processors coupled to the memory (e.g., implemented in a circuit). The one or more processors are configured to and capable of: obtaining a transform block; determining one or more non-zero decoded transform coefficients based at least in part on an analysis of the transform block; determining history update values ​​for the transform block based at least in part on the one or more non-zero decoded transform coefficients; updating existing history parameter values ​​at least in part by combining the history update values ​​for the transform block with existing history parameter values, the existing history parameter values ​​being based at least in part on a series of non-zero decoded transform coefficients determined from a series of previously analyzed transform blocks; and decoding at least one sample of the transform block based on the existing history parameter values ​​or the updated existing history parameter values.

[0032]

[0032] In another example, a non-transitory computer-readable medium is provided having stored thereon instructions that, when executed by one or more processors, cause the one or more processors to: obtain a transform block; determine one or more non-zero decoded transform coefficients based at least in part on an analysis of the transform block; determine a history update value for the transform block based at least in part on the one or more non-zero decoded transform coefficients; update an existing history parameter value at least in part by combining the history update value for the transform block with an existing history parameter value, the existing history parameter value being based at least in part on a series of non-zero decoded transform coefficients determined from a series of previously analyzed transform blocks; and decode at least one sample of the transform block based on the existing history parameter value or the updated existing history parameter value.

[0033]

[0033] In another example, an apparatus is provided, the apparatus including: means for obtaining a transform block; means for determining one or more non-zero decoded transform coefficients based at least in part on an analysis of the transform block; means for determining a history update value for the transform block based at least in part on the one or more non-zero decoded transform coefficients; means for updating an existing history parameter value at least in part by combining the history update value for the transform block with an existing history parameter value, the existing history parameter value being based at least in part on a series of non-zero decoded transform coefficients determined from a series of previously analyzed transform blocks; and means for decoding at least one sample of the transform block based on the existing history parameter value or the updated existing history parameter value.

[0034]

[0034] In another example, a method for encoding video data is provided, the method including: obtaining a transform block; determining one or more non-zero coded transform coefficients based at least in part on an analysis of the transform block; determining a history update value for the transform block based at least in part on the one or more non-zero coded transform coefficients; updating an existing history parameter value at least in part by combining the history update value for the transform block with an existing history parameter value, the existing history parameter value being based at least in part on a set of non-zero coded transform coefficients determined from a set of previously analyzed transform blocks; and generating a bitstream based on the existing history parameter value or the updated existing history parameter value.

[0035] In another example, an apparatus for encoding video data is provided, the apparatus including a memory and one or more processors coupled to the memory (e.g., implemented in circuitry). The one or more processors are configured to and capable of: obtaining a transform block; determining one or more non-zero coded transform coefficients based at least in part on an analysis of the transform block; determining history update values ​​for the transform block based at least in part on the one or more non-zero coded transform coefficients; updating existing history parameter values ​​at least in part by combining the history update values ​​for the transform block with existing history parameter values, the existing history parameter values ​​being based at least in part on a set of non-zero coded transform coefficients determined from a set of previously analyzed transform blocks; and generating a bitstream based on the existing history parameter values ​​or the updated existing history parameter values.

[0036]

[0036] In another example, a non-transitory computer-readable medium is provided having stored thereon instructions that, when executed by one or more processors, cause the one or more processors to: obtain a transform block; determine one or more non-zero decoded transform coefficients based at least in part on an analysis of the transform block; determine a history update value for the transform block based at least in part on the one or more non-zero decoded transform coefficients; update an existing history parameter value at least in part by combining the history update value for the transform block with an existing history parameter value, wherein the existing history parameter value is based at least in part on a series of non-zero decoded transform coefficients determined from a series of previously analyzed transform blocks; and generate a bitstream based on the existing history parameter value or the updated existing history parameter value.

[0037]

[0037] In another example, an apparatus is provided, the apparatus including: means for obtaining a transform block; means for determining one or more non-zero coded transform coefficients based at least in part on an analysis of the transform block; means for determining a history update value for the transform block based at least in part on the one or more non-zero coded transform coefficients; means for updating an existing history parameter value at least in part by combining the history update value for the transform block with an existing history parameter value, the existing history parameter value being based at least in part on a series of non-zero coded transform coefficients determined from a series of previously analyzed transform blocks; and means for generating a bitstream based on the existing history parameter value or the updated existing history parameter value.

[0038] In some aspects, combining the historical update values ​​of the transform block with the existing historical parameter values ​​comprises averaging the historical update values ​​of the transform block with the existing historical parameter values.

[0039]

[0039] In some aspects, combining the historical update values ​​of the transform block with the existing historical parameter values ​​comprises determining an exponentially weighted moving average between the historical update values ​​of the transform block and the existing historical parameter values.

[0040]

[0040] In some aspects, the methods, apparatus, and computer-readable media described above further comprise assigning a first weight to the historical update value of the transform block and a second weight to the existing historical parameter value, wherein determining the exponentially weighted moving average is based at least in part on the first weight and the second weight.

[0041] In some aspects, the history update value for a transform block is determined based on the first non-zero decoded transform coefficient determined in an analysis of the transform block.

[0042] In some aspects, the first non-zero decoded transform coefficient is determined based on a run scan order of the backward transform block.

[0043] In some aspects, the history update value of the transform block is determined at least in part by determining a binary code length of the first non-zero decoded transform coefficient.

[0044]

[0044] In some aspects, the transform block and a previously analyzed transform block are associated with a first slice, and existing history parameter values ​​are iteratively updated based on successive history update values ​​determined for successively analyzed transform blocks associated with the same slice.

[0045]

[0045] In some aspects, the methods, apparatus, and computer-readable media described above further comprise initializing existing history parameter values ​​to predetermined values, wherein the initialization is performed prior to analyzing the first transform block of the first slice and determining the history update values ​​for the first transform block.

[0046] In some aspects, the history update value for a transform block is determined based on all of the non-zero decoded transform coefficients of the transform block.

[0047] In some aspects, the history update value is determined at least in part by averaging all of the non-zero decoded transform coefficients of the transform block.

[0048]

[0048] In some aspects, decoding at least one sample of a transform block comprises decoding a syntax element indicating the at least one sample based on existing history parameter values ​​or updated existing history parameter values.

[0049] In some aspects, decoding at least one sample of the transform block comprises decoding a Golomb-Rice code using existing historical parameter values ​​or updated existing historical parameter values.

[0050] In some aspects, the apparatus may be or may be part of a mobile device (e.g., a mobile phone or so-called “smartphone,” or other mobile device), a personal computer, a laptop computer, an extended reality (XR) device (e.g., a virtual reality (VR) device, an augmented reality (AR) device, or a mixed reality (MR) device), an Internet of Things (IoT) device, a vehicle or a vehicle computing component or system, a smart wearable device, a server computer, a camera (e.g., a digital camera, an Internet Protocol (IP) camera, etc.), a multi-camera system, a robotics device or system, an aerial device or system, or other device. In some aspects, the apparatus includes a camera or multiple cameras for capturing one or more images. In some aspects, the apparatus includes a display for displaying one or more images, notifications, and / or other displayable data. In some aspects, the apparatus described above may include one or more sensors.

[0051] This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used separately to determine the scope of the claimed subject matter, which subject matter should be understood by reference to the entire specification of this patent, any or all drawings, and appropriate portions of each claim.

[0052]

[0052] The above, together with other features and embodiments, will become more apparent with reference to the following specification, claims, and accompanying drawings.

[0053]

[0053] Exemplary embodiments of the present application are described in detail below with reference to the following figures: [Brief explanation of the drawings]

[0054] [Figure 1]

[0054] FIG. 1 is a block diagram illustrating an example of an encoding device and a decoding device, according to some examples. [Figure 2]

[0055] FIG. 10 illustrates an example of a Rice-derived template showing neighboring coefficients of a current coefficient, according to some examples. [Figure 3]

[0056] FIG. 1 illustrates an example of various transform units (TUs) overlaid with an exemplary Rice-derived template, according to some examples. [Figure 4]

[0057] 10A-10C illustrate examples of various classifications applied to samples of transform units based at least in part on the interaction between a Rice-derived template and the spatial location of the sample, according to some examples. [Figure 5]

[0058] FIG. 10 illustrates an example of a historical update of a historical counter to determine a historical Rice parameter value, according to some examples. [Figure 6]

[0059] 1 is a flowchart illustrating an example of a process for deriving Rice parameters, according to some examples. [Figure 7]

[0060] 10 is a flowchart illustrating another example of a process for deriving Rice parameters, according to some examples. [Figure 8]

[0061] 1 is a block diagram illustrating an exemplary video encoding device, according to some examples. [Figure 9]

[0062] 1 is a block diagram illustrating an exemplary video decoding device, according to some examples. DETAILED DESCRIPTION OF THE INVENTION

[0055]

[0063]

[0023] Several aspects and embodiments of the present disclosure are provided below. As will be apparent to one skilled in the art, some of these aspects and embodiments may be applied independently, and some of them may be applied in combination. In the following description, for purposes of explanation, specific details are set forth to provide a thorough understanding of the embodiments of the present application. However, it will be apparent that various embodiments may be practiced without these specific details. The figures and descriptions are not limiting.

[0056]

[0064] The following description provides only exemplary embodiments and is not intended to limit the scope, applicability, or configuration of the present disclosure. Rather, the following description of exemplary embodiments provides those skilled in the art with an enabling description for implementing the exemplary embodiments. It should be understood that various changes may be made in the function and arrangement of elements without departing from the spirit and scope of the present application, as set forth in the appended claims.

[0057]

[0065] Digital video data can contain large amounts of data, especially as the demand for high-quality video data continues to grow. For example, consumers of video data generally desire increasingly higher quality video with high fidelity, resolution, frame rates, etc. However, the large amounts of video data required to meet such demand can place a significant strain on communication networks as well as devices that process and store the video data.

[0058]

[0066] Video coding devices implement video compression techniques for efficiently encoding and decoding video data. Video compression techniques may include applying different prediction modes, including spatial prediction (e.g., intra-frame prediction or intra-prediction), temporal prediction (e.g., inter-frame prediction or inter-prediction), inter-layer prediction (across different layers of video data), and / or other prediction techniques, to reduce or remove redundancy inherent in video sequences. A video encoder may partition each picture of an original video sequence into rectangular regions called video blocks or coding units (described in more detail below). These video blocks may be coded using particular prediction modes.

[0059]

[0067] A video block may be divided into one or more groups of smaller blocks in one or more ways. A block may include a coding tree block, a prediction block, a transform block, and / or other suitable block. Generally, references to a "block" may refer to such a video block (e.g., a coding tree block, a coding block, a prediction block, a transform block, or other appropriate block or sub-block, as understood by those skilled in the art) unless otherwise specified. Furthermore, each of these blocks may also be referred to interchangeably herein as a "unit" (e.g., a coding tree unit (CTU), a coding unit, a prediction unit (PU), a transform unit (TU), etc.). In some cases, a unit may refer to a coding logical unit that is encoded in the bitstream, and a block may refer to a portion of a video frame buffer that a process is targeted to.

[0060]

[0068] In inter-prediction modes, a video encoder may search for a block similar to a block encoded in a frame (or picture) in another temporal location, called a reference frame or picture. The video encoder may limit its search to a certain spatial displacement from the block to be encoded. The best match may be identified using a two-dimensional (2D) motion vector that includes a horizontal displacement component and a vertical displacement component. In intra-prediction modes, the video encoder may use spatial prediction techniques to form a predicted block based on data from previously encoded neighboring blocks in the same picture.

[0061]

[0069] The video encoder may determine a prediction error. For example, the prediction may be determined as the difference between pixel values ​​in the block being coded and pixel values ​​in a predicted block. The prediction error is sometimes referred to as a residual. The video encoder may also apply a transform (e.g., a discrete cosine transform (DCT) or other suitable transform) to the prediction error to generate transform coefficients. After the transform, the video encoder may quantize the transform coefficients. The quantized transform coefficients and motion vectors may be represented using syntax elements and, together with control information, form a coded representation of the video sequence. In some instances, the video encoder may entropy code the quantized transform coefficients and / or syntax elements, thereby further reducing the number of bits required for their representation.

[0062]

[0070] After entropy decoding and dequantizing the received bitstream, the video decoder may use the syntax elements and control information described above to construct prediction data (e.g., a prediction block) for decoding the current frame. For example, the video decoder may add the predicted block and the compressed prediction error. The video decoder may determine the compressed prediction error by weighting the transform basis functions using the quantized coefficients. The difference between the reconstructed frame and the original frame is called the reconstruction error.

[0063]

[0071] Video coding may be performed according to a particular video coding standard. Examples of video coding standards include, but are not limited to, ITU-T H.261, ISO / IEC MPEG-1 Visual, ITU-T H.262 or ISO / IEC MPEG-2 Visual, ITU-T H.263, ISO / IEC MPEG-4 Visual, Advanced Video Coding (AVC) or ITU-T H.264 including scalable video coding (SVC) and multiview video coding (MVC) extensions, High Efficiency Video Coding (HEVC) or ITU-T H.265 including range and screen content coding, 3D video coding (3D-HEVC), multiview (MV-HEVC), and scalable (SHVC) extensions, Generic Video Coding (VVC) or ITU-T H.266 and its extensions, VP9, ​​Alliance of Open Media (AOMedia) Video 1 (AV1), Essential Video Coding (EVC), among others.

[0064]

[0072] As described above, a video encoder may entropy encode the quantized transform coefficients and / or syntax elements to generate a bitstream. A video decoder may entropy decode the bitstream using an inverse entropy coding process. In some examples, Rice coding using Rice parameters may be used to perform entropy coding (e.g., entropy encoding and / or decoding). In the current VVC standard, Rice parameters for normal residual coding (RRC) may be derived based on a template (also referred to as a Rice parameter derivation template) for determining (e.g., calculating, computing, etc.) the sum of neighboring transform coefficients and a lookup table that maps different possible sum values ​​to specific Rice parameter values. In this approach, the determined sum from the Rice parameter derivation template is used as an index into the lookup table of Rice parameter values. In one illustrative example, the Rice parameter derivation template may be applied on a grid of samples (e.g., a grid of 8×8 samples). In some cases, the grid may represent a transform block (TB) or transform unit (TU) obtained from a larger frame or slice of video data. To determine the Rice parameters for a current transform coefficient, the video encoder or decoder may utilize a template to identify one or more neighboring transform coefficients. The Rice parameter derivation template may be used to identify several neighboring coefficients (e.g., five neighboring coefficients) for a given current coefficient. The video encoder or decoder may then determine a sum of the absolute values ​​of the identified neighboring transform coefficients based on the template.

[0065]

[0073] Template-based methods for Rice parameter derivation (e.g., template-based Rice parameter derivation according to VVC Section 9.3.3.2 (e.g., unmodified Equation 1517), and various example modifications described below (e.g., modifications of Equation 1517) can, in some examples, take advantage of the fact that decoding is done in a backward pass, starting from the end of a block and proceeding toward its DC. Based on backward pass decoding performed per block (e.g., TU or TB), such Rice parameter derivation techniques can take advantage of one or more transform coefficients that were decoded earlier in the current TU.

[0066]

[0074] In some cases (e.g., in the case of high bit-depth coding), due to a high proportion of small-sized TUs or TBs (e.g., having a size of 4×4) whose transform coefficients are coded using the Golomb-Rice method, accurate Rice derivation cannot be performed for some transform coefficients, such as those that appear at the very beginning of TU decoding. For example, there may be an insufficient amount of non-zero neighboring transform coefficients available to perform template-based Rice parameter derivation for those coefficients that appear at the beginning of TU decoding (e.g., based on template-based Rice parameter derivation using some predetermined number of neighboring transform coefficients, such as 5).

[0067]

[0075] As described in further detail herein, systems, apparatuses, methods, and computer-readable media (collectively “systems and techniques”) for improving parameter derivation (e.g., Rice parameter derivation) are described herein. Such systems and techniques may be used for regular residual coding (RRC) in high bit-depth coding and / or for other video coding. According to some aspects, the systems and techniques may include performing Rice parameter derivation in the presence of one or more unavailable neighboring transform coefficients. For example, a video encoder and / or video decoder may determine that one or more neighboring transform coefficients specified by a Rice derivation template are unavailable for a current sample of a current TU (e.g., in the case of a decoder, a currently decoded sample of a currently decoded TU). The unavailable neighboring transform coefficients may be transform coefficients that are not located within the same TU as the currently decoded coefficient. For example, an unavailable neighboring transform coefficient may be determined to exist when the Rice derivation template spans one or more borders or edges of the currently decoded TU.

[0068]

[0076] Rather than ignoring unavailable neighboring transform coefficients or setting them equal to zero, the systems and techniques described herein may provide historical Rice parameter values ​​to be used in place of unavailable neighboring transform coefficients when performing template- and lookup-table-based Rice derivation. In some examples, the historical Rice parameter values ​​may be determined (e.g., calculated, computed, etc.) by maintaining one or more history counters that accumulate one or more first decoded non-zero transform coefficients obtained from previously decoded TUs. For example, the previously decoded TU and the currently decoded TU may be associated with the same frame, block, slice, or other partition of video data and history counter(s) maintained for the duration of the larger unit to which the currently decoded TU belongs. The history counter(s) may maintain a running sum of the first non-zero decoded transform coefficients from earlier TUs, from which an arithmetic average may be determined each time a historical Rice parameter value is queried or used to perform Rice derivation according to the systems and techniques described herein. In some examples, the one or more historical counters may implement a weighted average or an exponentially weighted moving average for historical Rice parameter values, as described in more depth below.

[0069]

[0077] Further details regarding the systems and techniques are described with respect to the figures.

[0070]

[0078] FIG. 1 is a block diagram illustrating an example of a system 100 including an encoding device 104 and a decoding device 112. The encoding device 104 may be part of a source device, and the decoding device 112 may be part of a receiving device. The source device and / or receiving device may include an electronic device such as a mobile or landline telephone handset (e.g., a smartphone, a cellular telephone, etc.), a desktop computer, a laptop or notebook computer, a tablet computer, a set-top box, a television, a camera, a display device, a digital media player, a video game console, a video streaming device, an Internet Protocol (IP) camera, or any other suitable electronic device. In some examples, the source device and the receiving device may include one or more wireless transceivers for wireless communication. The coding techniques described herein are applicable to video coding in various multimedia applications, including streaming video transmission (e.g., over the Internet), television broadcasting or transmission, encoding digital video for storage on a data storage medium, decoding digital video stored on a data storage medium, or other applications. As used herein, the term coding can refer to encoding and / or decoding. In some examples, the system 100 may support one-way or two-way video transmission to support applications such as video conferencing, video streaming, video playback, video broadcasting, gaming, and / or video telephony.

[0071]

[0079] Encoding device 104 (or encoder) may be used to encode video data using a video coding standard, format, codec, or protocol to generate an encoded video bitstream. Examples of video coding standards and formats / codecs include ITU-T H.261, ISO / IEC MPEG-1 Visual, ITU-T H.262 or ISO / IEC MPEG-2 Visual, ITU-T H.263, ISO / IEC MPEG-4 Visual, ITU-T H.264 (also known as ISO / IEC MPEG-4 AVC) including scalable video coding (SVC) and multiview video coding (MVC) extensions, High Efficiency Video Coding (HEVC) or ITU-T H.265, and Generic Video Coding (VVC) or ITU-T H.266. There are various extensions to HEVC that address multi-layer video coding, including range and screen content coding extensions, 3D video coding (3D-HEVC) and multiview extensions (MV-HEVC), and scalable extensions (SHVC). HEVC and its extensions were developed by the ITU-T Video Coding Experts Group (VCEG) and the ISO / IEC Motion Picture Experts Group (MPEG) Joint Collaboration Team on Video Coding (JCT-VC) and the Joint Collaboration Team on 3D Video Coding Extensions Development (JCT-3V). VP9, ​​AOMedia Video 1 (AV1), developed by the Alliance for Open Media (AOMedia), and Essential Video Coding (EVC) are other video coding standards to which the techniques described herein may be applied.

[0072]

[0080] The systems and techniques described herein may be applied to any existing video codec (e.g., VVC, HEVC, AVC, or other suitable existing video codec) and / or may be efficient coding tools for any video coding standard under development and / or future video coding standard. For example, the examples described herein may be implemented using a video codec such as VVC, HEVC, AVC, and / or extensions thereof. However, the techniques and systems described herein may also be applicable to other coding standards, codecs, or formats, such as MPEG, JPEG (or other coding standards for still images), VP9, ​​AV1, extensions thereof, or other suitable coding standards that are already available or not yet available or developed. For example, in some examples, encoding device 104 and / or decoding device 112 may operate according to a proprietary video codec / format, such as AV1, an extension of AVI, and / or a successor version of AV1 (e.g., AV2), or other proprietary format or industry standard. Thus, while the techniques and systems described herein may be described with reference to a particular video coding standard, those skilled in the art will appreciate that the description should not be construed as applying only to that particular standard.

[0073]

[0081] 1, video source 102 may provide video data to encoding device 104. Video source 102 may be part of a source device or part of a device other than the source device. Video source 102 may include a video capture device (e.g., a video camera, a camera phone, a video phone, etc.), a video archive containing stored video, a video server or content provider providing video data, a video feed interface receiving video from a video server or content provider, a computer graphics system for generating computer graphics video data, a combination of such sources, or any other suitable video source.

[0074]

[0082] The video data from the video source 102 may include one or more input pictures or frames. A picture or frame, in some cases, is a still image that is part of a video. In some examples, the data from the video source 102 may be a still image that is not part of a video. In HEVC, VVC, and other video coding specifications, a video sequence may include a series of pictures. A picture may include three sample arrays, denoted SL, SCb, and SCr. SL is a two-dimensional array of luma samples, SCb is a two-dimensional array of Cb chrominance samples, and SCr is a two-dimensional array of Cr chrominance samples. Chrominance samples are sometimes referred to herein as "chroma samples." A pixel can refer to all three components (luma and chroma samples) for a given location in the array of a picture. In other cases, a picture may be monochrome and include only an array of luma samples, in which case the terms pixel and sample may be used interchangeably. For example techniques described herein that refer to individual samples for purposes of explanation, the same techniques may be applied to pixels (e.g., all three sample components for a given location in an array of pictures). For example techniques described herein that refer to pixels (e.g., all three sample components for a given location in an array of pictures) for purposes of explanation, the same techniques may be applied to individual samples.

[0075]

[0083] The encoder engine 106 (or encoder) of the encoding device 104 encodes video data to generate a coded video bitstream. In some examples, a coded video bitstream (or "video bitstream" or "bitstream") is a series of one or more coded video sequences. A coded video sequence (CVS) starts with an access unit (AU) in a base layer that has a random access point picture with some properties and includes a series of AUs up to, but not including, the next AU in the base layer that has a random access point picture with some properties. For example, some properties of the random access point picture that starts the CVS may include a RASL flag equal to 1 (e.g., NoRaslOutputFlag). In other cases, the random access point picture (with a RASL flag equal to 0) does not start a CVS. An access unit (AU) includes one or more coded pictures and control information corresponding to coded pictures that share the same output time. At the bitstream level, coded slices of a picture are encapsulated in data units called network abstraction layer (NAL) units. For example, an HEVC video bitstream may contain one or more CVSs containing NAL units. Each NAL unit has a NAL unit header. In one example, the header is one byte in H.264 / AVC (excluding multi-layer extensions) and two bytes in HEVC. Syntax elements in the NAL unit header take designated bits and are therefore visible to all types of systems and transport layers, such as transport streams, real-time transport (RTP) protocols, file formats, among others.

[0076]

[0084] Two classes of NAL units exist in the HEVC standard, including video coding layer (VCL) NAL units and non-VCL NAL units. A VCL NAL unit contains one slice or slice segment (described below) of coded picture data, while a non-VCL NAL unit contains control information related to one or more coded pictures. In some cases, NAL units may be referred to as packets. An HEVC AU contains VCL NAL units containing coded picture data and non-VCL NAL units (if any) that correspond to the coded picture data.

[0077]

[0085] An NAL unit may contain a sequence of bits (e.g., a coded video bitstream, CVS of a bitstream, etc.) that form a coded representation of video data, such as a coded representation of a picture in a video. The encoder engine 106 generates coded representations of pictures by partitioning each picture into multiple slices. Slices are independent of other slices such that information in a slice is coded without dependency on data from other slices in the same picture. A slice includes one or more slice segments, including independent slice segments, and one or more dependent slice segments, if any, that depend on previous slice segments. A slice is partitioned into coding tree blocks (CTBs) of luma samples and chroma samples. A CTB of luma samples and one or more CTBs of chroma samples, along with syntax for the samples, are called a coding tree unit (CTU). A CTU is sometimes called a "treeblock" or "largest coding unit" (LCU). A CTU is the basic processing unit for HEVC encoding. A CTU may be split into multiple coding units (CUs) of various sizes. A CU contains luma and chroma sample arrays called coding blocks (CBs).

[0078]

[0086] The luma and chroma CBs may be further split into prediction blocks (PBs). A PB is a block of luma or chroma component samples that uses the same motion parameters for inter prediction or intra block copy prediction (when available or enabled for use). A luma PB and one or more chroma PBs, together with associated syntax, form a prediction unit (PU). For inter prediction, a set of motion parameters (e.g., one or more motion vectors, reference indexes, etc.) is signaled in the bitstream for each PU and used for inter prediction of the luma PB and one or more chroma PBs. The motion parameters are sometimes referred to as motion information. A CB may also be partitioned into one or more transform blocks (TBs). A TB represents a square block of color component samples to which a residual transform (e.g., the same two-dimensional transform in some cases) is applied to code the prediction residual signal. A transform unit (TU) represents a TB of luma and chroma samples and corresponding syntax elements.

[0079]

[0087] The size of a CU corresponds to the size of a coding mode and may be square in shape. For example, the size of a CU may be 8x8 samples, 16x16 samples, 32x32 samples, 64x64 samples, or any other appropriate size up to the size of the corresponding CTU. The phrase "NxN" is used herein to refer to the pixel dimensions of a video block in vertical and horizontal dimensions (e.g., 8 pixels x 8 pixels). The pixels in a block may be arranged in rows and columns. In some examples, a block may not have the same number of pixels in the horizontal direction as in the vertical direction. Syntax data associated with a CU may, for example, represent the partitioning of the CU into one or more PUs. The partitioning mode may differ between whether the CU is coded in an intra-prediction mode or an inter-prediction mode. The PU may be partitioned to be non-square in shape. Syntax data associated with a CU may also, for example, represent the partitioning of a CU into one or more TUs according to the CTU. The TUs may be square or non-square in shape.

[0080]

[0088] According to the HEVC standard, transforms may be performed using transform units (TUs). TUs may be different for different CUs. TUs may be sized based on the size of the PUs within a given CU. TUs may be the same size as or smaller than the PUs. In some examples, residual samples corresponding to a CU may be subdivided into smaller units using a quad-tree structure known as a residual quad-tree (RQT). Leaf nodes of the RQT may correspond to TUs. Pixel difference values ​​associated with the TUs may be transformed to generate transform coefficients. The transform coefficients may be quantized by the encoder engine 106.

[0081]

[0089] Once a picture of video data is partitioned into CUs, the encoder engine 106 predicts each PU using a prediction mode. The prediction unit or prediction block is subtracted from the original video data to obtain a residual (described below). For each CU, a prediction mode may be signaled in the bitstream using syntax data. The prediction mode may include intra-prediction (or intra-picture prediction) or inter-prediction (or inter-picture prediction). Intra-prediction exploits the correlation between spatially adjacent samples within a picture. For example, using intra-prediction, each PU is predicted from neighboring image data in the same picture using, for example, DC prediction to find the average value for the PU, planar prediction to fit a flat surface to the PU, directional prediction to extrapolate from neighboring data, or any other suitable type of prediction. Inter-prediction uses temporal correlation between pictures to derive motion-compensated predictions for blocks of image samples. For example, using inter-prediction, each PU is predicted using motion-compensated prediction from image data in one or more reference pictures (before or after the current picture in output order). The decision of whether to code a picture area using inter-picture prediction or intra-picture prediction may be made, for example, at the CU level.

[0082]

[0090] The encoder engine 106 and the decoder engine 116 (described in more detail below) may be configured to operate according to VVC. According to VVC, a video coder (such as the encoder engine 106 and / or the decoder engine 116) partitions a picture into multiple coding tree units (CTUs) (where a CTB for luma samples and one or more CTBs for chroma samples, together with syntax for the samples, are referred to as a CTU). The video coder may partition the CTUs according to a tree structure, such as a quad-tree binary tree (QTBT) structure or a multi-type tree (MTT) structure. The QTBT structure eliminates the concept of multiple partition types, such as the distinction between CUs, PUs, and TUs in HEVC. The QTBT structure includes two levels, including a first level partitioned according to quad-tree 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 tree correspond to coding units (CUs).

[0083]

[0091] In the MTT partitioning structure, blocks may be partitioned using quadtree partitioning, binary tree partitioning, and one or more types of tripletree partitioning. Tripletree partitioning is a partition in which a block is split into three sub-blocks. In some examples, tripletree partitioning splits a block into three sub-blocks without splitting the original block through the center. Partition types in MTT (e.g., quadtree, binary tree, and tripletree) can be symmetric or asymmetric.

[0084]

[0092] When operating according to the AV1 codec, encoding device 104 and decoding device 112 may be configured to code video data in blocks. In AV1, the largest coding block that can be processed is called a superblock. In AV1, a superblock can be either 128x128 luma samples or 64x64 luma samples. However, in successor video coding formats (e.g., AV2), a superblock can be defined by a different (e.g., larger) luma sample size. In some examples, a superblock is the top level of a block quadtree. Encoding device 104 may further partition the superblock into smaller coding blocks. Encoding device 104 may partition the superblock and other coding blocks into smaller blocks using square or non-square partitions. Non-square blocks may include N / 2xN, NxN / 2, N / 4xN, and NxN / 4 blocks. Encoding device 104 and decoding device 112 may perform separate prediction and transform processes for each of the coding blocks.

[0085]

[0093] AV1 also defines tiles of video data. A tile is a rectangular array of superblocks that may be coded independently of other tiles. That is, encoding device 104 and decoding device 112 may encode and decode coding blocks within a tile, respectively, without using video data from other tiles. However, encoding device 104 and decoding device 112 may perform filtering across tile boundaries. Tiles may be uniform or non-uniform in size. Tile-based coding may enable parallel processing and / or multithreading for encoder and decoder implementations.

[0086]

[0094] In some examples, the encoding device 104 and the decoding device 112 may use a single QTBT or MTT structure to represent each of the luminance and chrominance components, and in other examples, the video coder may use two or more QTBT or MTT structures, such as one QTBT or MTT structure for the luminance component and another QTBT or MTT structure for both chrominance components (or two QTBT and / or MTT structures for each chrominance component).

[0087]

[0095] The encoding device 104 and the decoding device 112 may be configured to use quadtree partitioning, QTBT partitioning, MTT partitioning, or other partitioning structures according to HEVC.

[0088]

[0096] In some examples, one or more slices of a picture are assigned a slice type. Slice types include an I slice, a P slice, and a B slice. An I slice (intra-frame, independently decodable) is a slice of a picture that is coded only by intra prediction. Therefore, an I slice is independently decodable because it only requires data within a frame to predict any prediction unit or predictive block of the slice. A P slice (unidirectionally predicted frame) is a slice of a picture that can be coded using both intra prediction and unidirectional inter prediction. Each prediction unit or predictive block in a P slice is coded using either intra prediction or inter prediction. When inter prediction is applied, a prediction unit or predictive block is predicted by only one reference picture, and therefore, the reference samples are from only one reference region of a frame. A B slice (bidirectionally predicted frame) is a slice of a picture that can be coded using both intra prediction and inter prediction (e.g., either bi-predictive or uni-predictive). A prediction unit or prediction block of a B slice may be bidirectionally predicted from two reference pictures, where each picture derives one reference region, and the sample sets of the two reference regions are weighted (for example, with equal weights or with different weights) to generate a prediction signal for the bidirectionally predicted block. As described above, the slices of a picture are coded independently. In some cases, a picture may be coded as just one slice.

[0089]

[0097] As mentioned above, intra-picture prediction exploits the correlation between spatially adjacent samples within a picture. There are multiple intra-prediction modes (also referred to as "intra modes"). In some examples, intra-prediction of luma blocks includes 35 modes, including planar mode, DC mode, and 33 angular modes (e.g., diagonal intra-prediction mode and angular modes adjacent to the diagonal intra-prediction mode). The 35 modes of intra-prediction are indexed as shown in Table 1 below. In other examples, more intra-modes may be defined, including prediction angles not already represented by the 33 angular modes. In other examples, the prediction angles associated with the angular modes may differ from those used in HEVC.

[0090] [Table 1]

[0091]

[0098] Inter-picture prediction uses temporal correlation between pictures to derive motion-compensated predictions for blocks of image samples. Using a translational motion model, the position of a block in a previously decoded picture (reference picture) is indicated by a motion vector (Δx, Δy), where Δx specifies the horizontal displacement of the reference block relative to the position of the current block and Δy specifies its vertical displacement. In some cases, the motion vector (Δx, Δy) may be of integer sample precision (also called integer precision), in which case the motion vector points to the integer pel grid (or integer pixel sampling grid) of the reference frame. In some cases, the motion vector (Δx, Δy) may be of fractional sample precision (also called fractional pel precision or non-integer precision) to more accurately capture the movement of underlying objects without being restricted to the integer pel grid of the reference frame. The precision of the motion vector may be represented by the quantization level of the motion vector. For example, the quantization level may be of integer precision (e.g., 1 pixel) or fractional pel precision (e.g., 1 / 4 pixel, 1 / 2 pixel, or other sub-pixel value). When the corresponding motion vector has fractional sample precision, interpolation is applied to the reference picture to derive the prediction signal. For example, samples available at integer positions may be filtered (e.g., using one or more interpolation filters) to estimate values ​​at fractional positions. A previously decoded reference picture is indicated by a reference index (refIdx) into a reference picture list. The motion vector and the reference index may be referred to as motion parameters. Two types of inter-picture prediction may be implemented, including uni-prediction and bi-prediction.

[0092]

[0099] In the case of inter-prediction using bi-prediction (also called bidirectional inter-prediction), two sets of motion parameters (Δx0, y0, refIdx0 and Δx1, y1, refIdx1) are used to generate two motion-compensated predictions (from the same reference picture or possibly from different reference pictures). For example, in the case of bi-prediction, each prediction block uses two motion-compensated prediction signals to generate a B prediction unit. The two motion-compensated predictions are combined to obtain a final motion-compensated prediction. For example, the two motion-compensated predictions may be combined by averaging. In another example, weighted prediction may be used, in which case different weights may be applied to each motion-compensated prediction. Reference pictures that may be used in bi-prediction are stored in two separate lists, denoted as List 0 and List 1. The motion parameters may be derived in the encoder using a motion estimation process.

[0093]

[0100] For inter-prediction using uni-prediction (also called unidirectional inter-prediction), one set of motion parameters (Δx0, y0, refIdx0) is used to generate a motion-compensated prediction from a reference picture. For example, for uni-prediction, each prediction block uses at most one motion-compensated prediction signal to generate a P prediction unit.

[0094]

[0101] A PU may include data related to the prediction process (e.g., motion parameters or other suitable data). For example, when a PU is encoded using intra prediction, the PU may include data representing an intra prediction mode for the PU. As another example, when a PU is encoded using inter prediction, the PU may include data defining a motion vector for the PU. The data defining a motion vector for the PU may represent, for example, a horizontal component (Δx) of the motion vector, a vertical component (Δy) of the motion vector, a resolution of the motion vector (e.g., integer precision, ¼-pixel precision, or ⅛-pixel precision), a reference picture to which the motion vector points, a reference index, a reference picture list for the motion vector (e.g., List 0, List 1, or List C), or any combination thereof.

[0095]

[0102] AV1 includes two general techniques for encoding and decoding coding blocks of video data. The two general techniques are intra-prediction (e.g., intra-frame prediction or spatial prediction) and inter-prediction (e.g., inter-frame prediction or temporal prediction). In the context of AV1, when predicting a block of a current frame of video data using an intra-prediction mode, encoding device 104 and decoding device 112 do not use video data from other frames of the video data. In most intra-prediction modes, video encoding device 104 encodes the block of the current frame based on the difference between sample values ​​in the current block and predicted values ​​generated from reference samples in the same frame. Video encoding device 104 determines the predicted values ​​generated from the reference samples based on the intra-prediction mode.

[0096]

[0103] After performing prediction using intra prediction and / or inter prediction, the encoding device 104 may perform transform and quantization. For example, after prediction, the encoder engine 106 may calculate a residual value corresponding to the PU. The residual value may comprise pixel difference values ​​between the current block of pixels being coded (PU) and a predictive block (e.g., a predicted version of the current block) used to predict the current block. For example, after generating a predictive block (e.g., issuing inter prediction or intra prediction), the encoder engine 106 may generate a residual block by subtracting the predictive block generated by the prediction unit from the current block. The residual block includes a set of pixel difference values ​​that quantify differences between pixel values ​​of the current block and pixel values ​​of the predictive block. In some examples, the residual block may be represented in a two-dimensional block format (e.g., a two-dimensional matrix or array of pixel values). In such examples, the residual block is a two-dimensional representation of pixel values.

[0097]

[0104] Any residual data that may remain after prediction is performed is transformed using a block transform, which may be based on a discrete cosine transform, a discrete sine transform, an integer transform, a wavelet transform, another suitable transform function, or any combination thereof. In some cases, one or more block transforms (e.g., size 32x32, 16x16, 8x8, 4x4, or other suitable size) may be applied to the residual data in each CU. In some embodiments, TUs may be used for the transform and quantization process implemented by the encoder engine 106. A given CU having one or more PUs may also include one or more TUs. As described in more detail below, residual values ​​may be transformed into transform coefficients using a block transform, and quantized and scanned using the TUs to generate serialized transform coefficients for entropy coding.

[0098]

[0105] In some embodiments, after intra-predictive coding or inter-predictive coding using the PU of a CU, encoder engine 106 may calculate residual data for the TUs of the CU. The PU may comprise pixel data in the spatial domain (or pixel domain). The TUs may comprise coefficients in the transform domain after application of a block transform. As mentioned above, the residual data may correspond to pixel difference values ​​between pixels of the uncoded picture and predicted values ​​corresponding to the PU. Encoder engine 106 may form TUs including the residual data for the CU and transform the TUs to generate transform coefficients for the CU.

[0099]

[0106] The encoder engine 106 may perform quantization of the transform coefficients. Quantization provides further compression by quantizing the transform coefficients to reduce the amount of data used to represent the coefficients. For example, quantization may reduce the bit depth associated with some or all of the coefficients. In one example, a coefficient with an n-bit value may be truncated to an m-bit value during quantization, where n is greater than m.

[0100]

[0107] Once quantization is performed, the coded video bitstream includes the quantized transform coefficients, prediction information (e.g., prediction modes, motion vectors, block vectors, etc.), partition information, and any other suitable data, such as other syntax data. Different elements of the coded video bitstream may be entropy coded by the encoder engine 106. In some examples, the encoder engine 106 may utilize a predefined scan order to scan the quantized transform coefficients to generate serialized vectors that can be entropy coded. In some examples, the encoder engine 106 may perform adaptive scanning. After scanning the quantized transform coefficients to form vectors (e.g., one-dimensional vectors), the encoder engine 106 may entropy code the vectors. For example, the encoder engine 106 may use context-adaptive variable length coding, context-adaptive binary arithmetic coding, syntax-based context-adaptive binary arithmetic coding, probability interval partition entropy coding, or another suitable entropy coding technique.

[0101]

[0108] An output 110 of the encoding device 104 may send the NAL units constituting the encoded video bitstream data to a decoding device 112 of a receiving device via a communication link 120. An input 114 of the decoding device 112 may receive the NAL units. The communication link 120 may include channels provided by a wireless network, a wired network, or a combination of wired and wireless networks. The wireless network may include any wireless interface or combination of wireless interfaces, including any suitable wireless network (e.g., the Internet or other wide area network, a packet-based network, WiFi, radio frequency (RF), UWB, WiFi-Direct, cellular, Long Term Evolution (LTE), WiMax, etc.). The wired network may include any wired interface (e.g., fiber, Ethernet, powerline Ethernet, Ethernet over coaxial cable, digital signal line (DSL), etc.). Wired and / or wireless networks may be implemented using a variety of equipment, such as base stations, routers, access points, bridges, gateways, switches, etc. The encoded video bitstream data may be modulated according to a communication standard, such as a wireless communication protocol, and transmitted to a receiving device.

[0102]

[0109] In some examples, encoding device 104 may store the encoded video bitstream data in storage device 108. Output 110 may retrieve the encoded video bitstream data from encoder engine 106 or from storage device 108. Storage device 108 may include any of a variety of distributed or locally accessed data storage media. For example, storage device 108 may include a hard drive, a storage disk, flash memory, volatile or non-volatile memory, or any other suitable digital storage medium for storing encoded video data. Storage device 108 may also include a decoded picture buffer (DPB) for storing reference pictures for use in inter-prediction. In further examples, storage device 108 may correspond to a file server or another intermediate storage device capable of storing encoded video generated by a source device. In such cases, receiving devices including decoding device 112 can access the stored video data from the storage device via streaming or download. The file server may be any type of server capable of storing encoded video data and transmitting the encoded video data to receiving devices. Exemplary file servers include web servers (e.g., for websites), FTP servers, network-attached storage (NAS) devices, or local disk drives. The receiving device may access the encoded video data through any standard data connection, including an Internet connection, and may include a wireless channel (e.g., a Wi-Fi connection), a wired connection (e.g., DSL, cable modem, etc.), or a combination of both, that is suitable for accessing encoded video data stored on a file server. The transmission of the encoded video data from storage device 108 may be a streaming transmission, a download transmission, or a combination thereof.

[0103]

[0110] An input 114 of the decoding device 112 may receive encoded video bitstream data and provide the video bitstream data to the decoder engine 116 or to the storage device 118 for later use by the decoder engine 116. For example, the storage device 118 may include a DPB for storing reference pictures for use in inter-prediction. A receiving device including the decoding device 112 may receive encoded video data to be decoded via the storage device 108. The encoded video data may be modulated according to a communication standard, such as a wireless communication protocol, and transmitted to the receiving device. The communication medium for the transmitted encoded video data may comprise 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 to a receiving device.

[0104]

[0111] The decoder engine 116 may decode the encoded video bitstream data by entropy decoding (e.g., using an entropy decoder) to extract elements of one or more coded video sequences that make up the encoded video data. The decoder engine 116 may rescale the encoded video bitstream data and perform an inverse transform on the encoded video bitstream data. Residual data is passed to a prediction stage of the decoder engine 116. The decoder engine 116 predicts blocks of pixels (e.g., PUs). In some examples, the prediction is added to the output of the inverse transform (the residual data).

[0105]

[0112] Decoding device 112 may output the decoded video to video destination device 122, which may include a display or other output device for displaying the decoded video data to a content consumer. In some aspects, video destination device 122 may be part of a receiving device that includes decoding device 112. In some aspects, video destination device 122 may be part of a separate device other than the receiving device.

[0106]

[0113] In some examples, the video encoding device 104 and / or the video decoding device 112 may be integrated with an audio encoding device and an audio decoding device, respectively. The video encoding device 104 and / or the video decoding device 112 may also include other hardware or software necessary to implement the coding techniques described above, 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. The video encoding device 104 and the video decoding device 112 may be integrated as part of a combined encoder / decoder (codec) in their respective devices. An example of specific details of the encoding device 104 is described below with reference to FIG. 8. An example of specific details of the decoding device 112 is described below with reference to FIG. 9.

[0107]

[0114] The exemplary system shown in FIG. 1 is one illustrative example that may be used herein. Techniques for processing video data using the techniques described herein may be implemented by any digital video encoding and / or decoding device. Generally, the techniques of this disclosure are implemented by a video encoding device or a video decoding device, although the techniques may also be implemented by a composite video encoder / decoder, commonly referred to as a "codec." Additionally, the techniques of this disclosure may also be implemented by a video preprocessor. The source device and the receiving device are merely examples of coding devices, such that the source device generates coded video data for transmission to the receiving device. In some examples, the source device and the receiving device may operate substantially symmetrically, such that each device includes a video encoding component and a video decoding component. Thus, the exemplary system may support one-way or two-way video transmission between video devices, for example, for video streaming, video playback, video broadcasting, or video telephony.

[0108]

[0115] Extensions to the HEVC standard include a multiview video coding extension called MV-HEVC and a scalable video coding extension called SHVC. MV-HEVC and SHVC extensions share the concept of layered coding, in which different layers are included in a coded video bitstream. Each layer in a coded video sequence is addressed by a unique layer identifier (ID). The layer ID may be present in the header of an NAL unit to identify the layer to which the NAL unit is associated. In MV-HEVC, different layers can represent different views of the same scene in a video bitstream. In SHVC, different scalable layers are provided to represent a video bitstream at different spatial resolutions (or picture resolutions) or with different reconstruction fidelity. The scalable layers may include a base layer (with layer ID = 0) and one or more enhancement layers (with layer ID = 1, 2, ... n). The base layer may conform to the HEVC first version profile and represent the lowest available layer in the bitstream. Enhancement layers have increased spatial resolution, temporal resolution or frame rate, and / or reconstruction fidelity (or quality) compared to the base layer. Enhancement layers are organized hierarchically and may or may not depend on lower layers. In some examples, different layers may be coded using a single-standard codec (e.g., all layers are encoded using HEVC, SHVC, or other coding standard). In some examples, different layers may be coded using a multi-standard codec. For example, the base layer may be coded using AVC, while one or more enhancement layers may be coded using SHVC and / or MV-HEVC extensions to the HEVC standard.

[0109]

[0116] Generally, a layer includes a set of VCL NAL units and a corresponding set of non-VCL NAL units. NAL units are assigned specific layer ID values. Layers may be hierarchical, in the sense that a layer may depend on a lower layer. A layer set refers to a set of layers represented in a bitstream that is self-contained, meaning that a layer in a layer set may depend on other layers in the layer set in the decoding process, but does not depend on any other layers for decoding. Thus, layers in a layer set can form an independent bitstream that can represent video content. A set of layers in a layer set can be obtained from another bitstream by the operation of a sub-bitstream extraction process. A layer set may correspond to a set of layers to be decoded when a decoder wishes to operate according to certain parameters.

[0110]

[0117] As previously described, an HEVC bitstream includes a group of NAL units, including VCL NAL units and non-VCL NAL units. VCL NAL units include coded picture data that form a coded video bitstream. For example, a sequence of bits that form a coded video bitstream resides in a VCL NAL unit. Non-VCL NAL units may include, among other information, parameter sets with high-level information related to the coded video bitstream. For example, the parameter sets may include a video parameter set (VPS), a sequence parameter set (SPS), and a picture parameter set (PPS). Example parameter set goals include bitrate efficiency, error resiliency, and providing a system layer interface. Each slice references a single active PPS, SPS, and VPS to access information that decoding device 112 can use to decode that slice. An ID, including a VPS identifier (ID), an SPS ID, and a PPS ID, may be coded for each parameter set. The SPS includes an SPS ID and a VPS ID. The PPS includes a PPS ID and an SPS ID. Each slice header includes a PPS ID. The IDs can be used to identify the active parameter set for a given slice.

[0111]

[0118] A PPS contains information that applies to all slices in a given picture. In some examples, all slices in a picture point to the same PPS. Slices in different pictures may also point to the same PPS. An SPS contains information that applies to all pictures in the same coded video sequence (CVS) or bitstream. As previously described, a coded video sequence is a series of access units (AUs) starting with a random access point picture with some properties (e.g., an instantaneous decode reference (IDR) picture or a broken link access (BLA) picture, or other suitable random access point picture) in the base layer (described above) up to, but not including, the next AU (or the end of the bitstream) that has a random access point picture with some properties in the base layer. The information in an SPS may not change from picture to picture within a coded video sequence. Pictures in a coded video sequence may use the same SPS. A VPS contains information that applies to all layers in a coded video sequence or bitstream. The VPS includes a syntax structure with syntax elements that apply to the entire coded video sequence. In some embodiments, the VPS, SPS, or PPS may be transmitted in-band with the coded bitstream. In some embodiments, the VPS, SPS, or PPS may be transmitted out-of-band in a transmission separate from the NAL units containing the coded video data.

[0112]

[0119] This disclosure may generally refer to “signaling” certain information, such as syntax elements. The term “signaling” may generally refer to communication of values ​​for syntax elements and / or other data used to decode encoded video data. For example, video encoding device 104 may signal values ​​for syntax elements in a bitstream. Generally, signaling refers to generating values ​​in the bitstream. As mentioned above, video source 102 may transport the bitstream to video destination device 122 in substantially real time or non-real time, such as may occur when storing syntax elements in storage device 108 for later retrieval by video destination device 122.

[0113]

[0120] A video bitstream may also include supplemental enhancement information (SEI) messages. For example, an SEI NAL unit may be part of the video bitstream. In some cases, the SEI message may contain information that is not required by the decoding process. For example, the information in the SEI message may not be essential for a decoder to decode video pictures of the bitstream, but the decoder may use the information to improve the display or processing of the pictures (e.g., the decoded output). The information in the SEI message may be embedded metadata. In one illustrative example, the information in the SEI message may be used by a decoder-side entity to improve the viewability of the content. In some cases, some application standards may specify the presence of such SEI messages in a bitstream so that quality improvements can be provided to all devices that comply with the application standard (e.g., the carriage of a frame packing SEI message for a frame-compatible planar stereoscopic 3DTV video format, where a frame packing SEI message is carried for every frame of video, the processing of a recovery point SEI message, the use of a pan-scan scan rectangle SEI message in DVB, among many other examples).

[0114]

[0121] As described above, encoding device 104 may entropy code the quantized transform coefficients and / or syntax elements to generate a bitstream. Decoding device 112 may receive and entropy decode the bitstream. In some examples, encoding device 104 and / or decoding device 112 may utilize Rice coding using Rice parameters to perform entropy coding (e.g., entropy encoding and / or decoding). According to the current VVC standard, Rice parameters for normal residual coding (RRC) may be derived based on a template for calculating the sum of neighboring transform coefficients and a lookup table that maps various possible sum values ​​to specific Rice parameter values. In this approach, the calculated sum from the template is used as an index into the lookup table of Rice parameter values. An exemplary template is shown in FIG. 2, described below. An example of a lookup table of Rice parameter values ​​is provided in Table 1 below.

[0115]

[0122] FIG. 2 is a diagram illustrating an example of a template for Rice parameter derivation. In the example of FIG. 2, the template is shown as being applied to an 8×8 grid of samples, although a larger or smaller number of samples (and larger or smaller grids) may be utilized. In some cases, the 8×8 grid may represent a transform block or transform unit (TU) obtained from a larger frame or slice of video data. As illustrated, to determine the Rice parameters for a current transform coefficient (e.g., shaded with solid black fill), the video coder may first utilize the template to identify one or more neighboring transform coefficients (e.g., lightly shaded with diagonal fill). As shown in FIG. 2, the Rice parameter derivation template identifies five neighboring coefficients for a given current coefficient, although a larger or smaller number of neighboring coefficients and / or different patterns and arrangements of neighboring coefficients may be utilized.

[0116]

[0123] The video coder may then determine a sum of the absolute values ​​of the identified neighboring transform coefficients based on the template (e.g., locSumAbs). In some examples, the resulting sum of the neighboring transform coefficients may be provided directly as an index into the lookup table of Table 1 to thereby obtain the Rice parameter value of the current coefficient. In one example, locSumAbs may be normalized (e.g., via subtraction and clip operations) before being provided as an index into Table 1, as follows:

[0117]

number

[0118]

[0124] As mentioned above, the rice parameters may be derived using the value of locSumAbs as an index into a lookup table. An example of a lookup table that maps between locSumAbs values ​​and rice parameter values ​​(e.g., cRiceParam) is provided below in Table 1.

[0119] [Table 2]

[0120]

[0125] As shown in Table 1, in some examples, the range of values ​​for the Rice parameter may be constrained to be between 0 and 3, inclusive. Because the raw locSumAbs values ​​are normalized (e.g., via the example normalization operation provided above) to be between 0 and 31, Table 1 may be used to derive the Rice parameter values ​​for all possible values ​​of locSumAbs that may be output by the normalization operation.

[0121]

[0126] The Rice parameter derivation process given by section 9.3.3.2 of the VVC specification is reproduced below for reference.

[0122] [Table 3]

[0123] [Table 4]

[0124]

[0127] In some cases, the Rice parameter derivation of VVC 9.3.3.2 may be modified, e.g., based on the observation that, due to the high bit-depth extension of VVC, high bit-depth video data may otherwise suffer performance and / or efficiency limitations under the unmodified Rice parameter derivation process of VVC 9.3.3.2. The modified Rice parameter derivation may therefore be used to address one or more of these limitations in various input bit depths of video, and thus improve the compression efficiency of the coding design. For example, in some examples, the modified Rice parameter derivation may include scaling or normalizing locSumAbs to handle increased bit depths and / or increased dynamic ranges of the transform coefficients. As previously described, scaling and normalization may be performed prior to using locSumAbs to derive the Rice parameters. In some examples, modified equation 1517 of the VVC specification may be used.

[0125]

[0128] A first example of modified equation 1517 for Rice parameter derivation is provided below and annotated to show the modifications to VVC 9.3.3.2. The amount of the scaling factor applied may depend on the input bit depth, a predefined operation bit depth (e.g., 10), the local activity of the transform coefficients, and / or the block size or syntax elements signaled in the bitstream. locSumAbs may then be clipped to a specific range, for example, using an existing clipping mechanism in VVC that clips locSumAbs to be between 0 and 31. The normalized and clipped locSumAbs may then be used to derive Rice parameter values ​​using a predefined lookup table, for example, the current lookup table in VVC, Table 128 (which is the same as Table 1 above). The Rice parameter values ​​from the lookup table may then be modified by adding an offset to expand the dynamic range of the Rice parameter range. Below is an example modification of section 9.3.3.2 of the VVC specification using the example technique described above (additions are indicated by underlined text: addition ") is indicated).

[0126] [Table 5]

[0127] In some examples, additional variables a, b, and c may be defined as follows: variable a may be an integer value, e.g., a=4, or some other power of 2, variable b may specify the operation bit depth, e.g., b=10, and variable c may be set equal to the calculated value shift introduced above in modified equation 1517 or may be derived from the calculated shift value.

[0128]

[0129] A second example of modified equation 1517 for Rice parameter derivation is provided below, again annotated to show the modifications made to VVC9.3.3.2. In this second example of modified equation 1517, locSumAbs may be scaled and / or normalized only when locSumAbs is greater than or equal to a threshold T. In such an example, the Rice parameter derivation process given by VVC9.3.3.2 may be modified accordingly as follows (additions are indicated by underlined text (" addition ") is indicated).

[0129] [Table 6]

[0130] In some examples, the threshold T is a predefined threshold. In one illustrative example, the threshold T may be set equal to 32. In some examples, the values ​​of one or more of the variables a, b, and c may be signaled through the bitstream. Additionally or alternatively, the values ​​of one or more of the variables a, b, and c may be set according to or derived from one or more of the bit depth, local statistics (e.g., minimum / maximum or average values ​​of transform coefficient values ​​in the current block), decoded transform or block size, and / or syntax elements signaled in the bitstream. In some cases, the values ​​of one or more of the variables a, b, and c used in the second modification of Equation 1517 immediately above may be the same as or otherwise similar to the corresponding values ​​of one or more of the variables a, b, and c used in the first modification of Equation 1517 discussed previously.

[0131]

[0131] Template-based methods for Rice parameter derivation under VVC9.3.3.2 (e.g., unmodified Equation 1517) and the various modifications described above (e.g., the first and second modifications of Equation 1517) can, in some instances, take advantage of the fact that decoding is done in a backward pass, starting from the end of a block and proceeding toward its DC. Based on backward pass decoding performed per block or TU, these previously described approaches to Rice parameter derivation can take advantage of one or more transform coefficients that were decoded earlier in the current TU.

[0132]

[0132] In VVC development, several statistical assumptions were made that suggested that non-zero transform coefficients (e.g., context coded) could be used to provide accurate Rice parameter derivation using the Golomb-Rice method. Further statistical assumptions during VVC development suggested that these non-zero transform coefficients be available to the decoder before the decoder begins transform coefficient decoding. Such assumptions appear to hold for the Common Test Condition (CTC) coding utilized in VVC development.

[0133] However, in some cases (e.g., in the case of high bit-depth coding), when there is a high proportion of small-sized (e.g., 4×4-sized) TUs whose transform coefficients are coded using the Golomb-Rice method, it is observed that accurate Rice derivation cannot be performed for the transform coefficients that appear at the very beginning of TU decoding. In particular, the amount of non-zero neighboring transform coefficients available to perform template-based Rice parameter derivation for those coefficients that appear at the beginning of TU decoding may be insufficient (recall that template-based Rice parameter derivation uses some predetermined number of neighboring transform coefficients, such as 5).

[0134] As explained above, systems and techniques for improving parameter derivation (e.g., Rice parameter derivation) in video coding are described herein. The systems and techniques may be implemented by encoding device 104, decoding device 112, by both encoding device 104 and decoding device 112, and / or by other devices. In some cases, encoding device 104 and / or decoding device 112 may use one or more historical Rice parameter values ​​for Rice parameter derivation when an insufficient number of neighboring transform coefficients are available. For example, the number of neighboring transform coefficients may be less than a predefined amount required to fully utilize a template-based lookup table approach to Rice parameter derivation (e.g., an approach used in VVC and / or other video coding standards). Rather than ignoring unavailable neighboring transform coefficients or setting them equal to 0, the systems and techniques described herein may provide historical Rice parameter values ​​to be used in place of unavailable neighboring transform coefficients when implementing template- and lookup table-based Rice derivation. In some examples, the systems and techniques described herein may be used in the context of high bit depth coding, where the shortcomings of existing Rice parameter derivation techniques based on lookup tables may be encountered more than usual.

[0135]

[0135] Figure 3 illustrates different exemplary scenarios in which the template support area (e.g., consisting of at least five neighboring transform coefficients 312, 314, 315, 316, and 318 associated with a current coefficient 302) extends outside a coded transform block or TU, thus resulting in a lower-accuracy Rice parameter derivation. As shown in Figure 3, an 8x8 sample grid 300 is shown overlaid with the boundaries of three different transform blocks 320, 330, and 340 (e.g., TUs). All three of the transform blocks 320, 330, and 340 include a current coefficient 302, which represents the sample or coefficient for which transform block (e.g., TU) decoding and / or Rice parameter derivation is currently being performed. However, the location of the current coefficient 302 within the transform blocks 320, 330, and 340 is such that one or more of the five neighboring transform coefficients defined by the Rice derivation template are located outside (e.g., beyond) the transform block (e.g., TU).

[0136] As previously discussed, decoding may be performed in a backward pass over constituent samples within a transform block (or TU), such as starting with the bottom-right sample of the transform block. For example, the bottom-right sample of transform block 320 is the current coefficient 302, and therefore, the current coefficient 302 is the first sample decoded for transform block 320. For transform blocks 330 and 340, although the current coefficient 302 is not the bottom-right sample, the current coefficient 302 remains among the first few samples to be decoded in the backward pass. In general, it may be observed that the geometry of a Rice-derived template may not be completely contained within the boundary or border of a transform block (e.g., a TU) due to samples located near the bottom and / or right edges of the transform block. Thus, in some cases, the first sample to be decoded in the backward pass may not be able to fully utilize the template-based approach to Rice parameter derivation described above.

[0137] In some examples, neighboring transform coefficients located outside the template support area or outside the current transform block (e.g., the current TU) may be treated as having a value of 0 for purposes of determining (e.g., calculating, computing, etc.) the absolute value sum locSumAbs. For example, neighboring transform coefficients 312, 314, 315, and 318 are all located outside transform block 340 (e.g., the TU), and only neighboring transform coefficient 316 is inside transform block 340. In such examples, proceeding with the Rice parameter derivation based only on transform coefficient 316 may result in a less accurate Rice parameter derivation. For some transform blocks (e.g., transform block 320, etc.), when all of the neighboring transform coefficients defined by the template are located outside the transform block, it may not be possible to derive Rice parameters using the template and lookup table approach specified in VVC and other video coding standards.

[0138]

[0138] Thus, the systems and techniques described herein may be used to improve the accuracy of Rice parameter derivation, at least in part, by determining (e.g., calculating, computing, etc.) and maintaining one or more historical values ​​of optimal Rice parameters. In some cases, the historical values ​​of the optimal Rice parameters may be determined from earlier decoded or coded transform coefficients (e.g., transform coefficients outside the current transform block that were decoded or coded at some earlier time in a backward pass). In some examples, the one or more historical values ​​of the optimal Rice parameters may be utilized as historical parameter values ​​determined from one or more previously coded transform blocks, where the historical parameter values ​​are used to determine the parameters (e.g., Rice parameters) of the current sample. In some examples, the historical parameter values ​​may include one or more of historical Rice parameter values ​​and historical transform coefficient values, where the historical transform coefficient values ​​are determined from one or more previously coded transform blocks. In some cases, the historical parameter values ​​may be historical transform coefficient values. In some examples, the historical parameter values ​​may be offset values ​​that may be derived externally. When the history parameter value is an offset value, the offset value may be determined based at least in part on one or more transform coefficient values ​​determined from a previously coded transform block and / or may be a predetermined offset value.

[0139] In some examples, when one or more neighboring transform coefficients provided by a Rice-derived template are located outside the current transform block, one or more historical Rice parameter values ​​may be used in determining (e.g., calculating, computing, etc.) the absolute sum locSumAbs. For example, rather than treating unavailable neighboring transform coefficients as having a zero value, the unavailable neighboring transform coefficients may instead be assigned historical Rice parameter values. In the example context and transform block 340 of FIG. 3, the unavailable neighboring transform coefficients are 312, 314, 315, and 318. Thus, in the example transform block 340, all four unavailable neighboring transform coefficients 312, 314, 315, and 318 may be assigned historical Rice parameter values. In some cases, the same historical Rice parameter value may be assigned to all of the unavailable neighboring transform coefficients; however, the historical Rice parameter value may also be modified or adjusted based on information and characteristics specific to each of the unavailable neighboring transform coefficients.

[0140] In some examples, the absolute sum locSumAbs may be calculated using a combination of historical Rice parameter values ​​and values ​​of available neighboring transform coefficients. This may be referred to as a partially unavailable case, where some, but not all, of the neighboring transform coefficients provided by the Rice-derived template are located outside the current transform block (e.g., TU). In the context of transform block 340, the absolute sum locSumAbs may therefore be calculated as the sum of the absolute values ​​of the available transform coefficients 316 and four historical Rice parameter values ​​obtained or otherwise determined for the four unavailable transform coefficients 312, 314, 315, 318. As mentioned above, the four historical Rice parameter values ​​may be the same or may be determined specifically for a given one of the unavailable transform coefficients.

[0141] Additionally or alternatively, the absolute sum locSumAbs may be calculated using only historical Rice parameter values. This may be referred to as the completely unavailable case, where all of the neighboring transform coefficients provided by the Rice-derived template are located outside the current transform block. For example, with reference to transform block 320, it can be seen that all five of neighboring transform coefficients 312, 314, 315, 316, and 318 are unavailable with respect to current coefficient 302 of transform block 320. Accordingly, in this completely unavailable case, the absolute sum locSumAbs may be calculated as the sum of five historical Rice parameter values ​​obtained or otherwise determined for the five unavailable transform coefficients. As previously mentioned, the five historical Rice parameter values ​​may be the same or may be determined specifically for a given transform coefficient among the unavailable transform coefficients.

[0142] In some examples, the systems and techniques disclosed herein (e.g., implemented by encoding device 104 and / or decoding device 112) may classify the spatial locations of decoded coefficients within a transform block (e.g., TU) based on the expected (or estimated) accuracy of a template-based Rice derivation method for the coefficient. One illustrative example of classification based on the expected accuracy of a template-based Rice derivation is shown in FIG. 4. In some cases, the 8×8 sample grid shown in FIG. 4 may be the same as or similar to the 8×8 sample grid discussed above with respect to FIG. 3. Similarly, the relative locations of the five neighboring transform coefficients with respect to a current coefficient may be the same in FIG. 4 as in FIG. 3, e.g., both figures utilize the same exemplary Rice derivation template.

[0143] Classification of the expected accuracy of a template-based Rice derivation can be based, at least in part, on the observation that the Rice derivation template identifies the locations of neighboring coefficients relative to the location of a current coefficient in a consistent manner (e.g., the same template is used each time Rice parameter derivation is performed). Thus, given the location of a current coefficient within a transform block (e.g., a TU) and the shape of the Rice derivation template, the number of neighboring transform coefficients that fall outside the boundary of the TU can be determined in advance. This number of unavailable neighboring transform coefficients can then be used to predict or estimate the accuracy of the Rice parameter derivation that should result from the template-based method. In some examples, the number of unavailable neighboring transform coefficients and / or the expected accuracy of the Rice derivation can further determine how historical Rice parameter values ​​are used (e.g., whether the systems and techniques of this disclosure are applied in the case of partial or complete unavailability).

[0144] 4 shows an 8x8 grid of samples 400. The sample grid 400 may be transform units (TUs) or coding blocks and is divided into four non-overlapping regions 410, 420, 430, and 440. As shown, each region may be assigned a different classification (e.g., C1, C2, C3, C4) according to the expected accuracy of the Rice parameter derivation. In other words, the expected accuracy of the Rice parameter derivation is the same for all of the samples within each region, but may not necessarily be the same for samples located in different regions.

[0145]

[0145] Samples (and associated transform coefficients) whose spatial locations lie within the first region 410 are denoted as class C1. Samples with a C1 classification may be samples that are expected to have an accurate Rice parameter derivation (e.g., greater than an accuracy threshold) using a template-based method. According to such an example, the Rice parameter derivation for a C1 coefficient may be determined (e.g., by video encoding device 104 and / or video decoding device 112) as follows:

[0146]

number

[0147] Here, template_based_method() may be provided as the template-based Rice parameter derivation defined in VVC section 9.3.3.2 (reproduced above). In some examples, template_based_method() may be implemented using one or more of the possible modifications to VVC 9.3.3.2, also described above.

[0148] Samples (and associated transform coefficients) whose spatial locations lie within the fourth region 440 are denoted as class C4. Samples with a C4 classification may be samples that are expected to have an inaccurate Rice parameter derivation (e.g., less than an accuracy threshold or zero accuracy) using one or more of the template-based methods previously described herein. In one illustrative example, video encoding device 104 and / or video decoding device 112 may instead use a history-based derivation method to obtain an accurate Rice parameter derivation (e.g., by using one or more historical estimates of optimal Rice parameters derived from a history of previously decoded coefficients). According to such an example, video encoding device 104 and / or video decoding device 112 may determine a Rice parameter derivation for a C4 coefficient as follows:

[0149]

number

[0150]

[0147] Samples (and associated transform coefficients) whose spatial locations lie within the second region 420 are denoted as class C2. Samples and transform coefficients whose spatial locations lie within the third region are denoted as class C3. Samples with a C2 or C3 classification may be samples that are expected to have a Rice parameter derivation of reduced accuracy (e.g., less than an accuracy threshold) using one or more of the template-based methods or modifications thereof previously described herein. In one illustrative example, the accuracy of the Rice parameter derivation of C2 and C3 coefficients may be improved by combining a template-based method, e.g., template_based_method(), with a history-based derivation method, e.g., history_based_method(). According to such an example, video encoding device 104 and / or video decoding device 112 may derive Rice parameters for C2 and / or C3 coefficients as follows:

[0151]

number

[0152]

[0148] In some examples, the classification can be based on a run of scan order in the reverse direction, for example, assigning the first N decoded coefficients to C4 and the remaining coefficients being classified as C1 (recall that the reverse scan order starts from the bottom right sample, which would now be located at C4).

[0153] In some cases, video encoding device 104 and / or video decoding device 112 may use a subset of one or more of the defined classes described above. For example, in some cases, only decoded coefficients of the C4 class may use historical Rice information because the template-based method may have an insufficient amount of neighboring coefficient values ​​to derive Rice parameters for a current coefficient located in C4 region 440. The C1 class does not use historical Rice information to perform Rice parameter derivation for a current coefficient located in C1 region 410. This is because, for every possible location with C1, all neighboring coefficients defined by the Rice template are still contained within the entire TU 400. Thus, in some examples, support for the C1 class may be extended to incorporate one or more of C2 region 420, C3 region 430, and / or the entire TU 400, in each case where historical information is not used for Rice derivation.

[0154] To utilize the techniques described herein, video encoding device 104 and / or video decoding device 112 may apply different techniques for aggregation of local and historical information to derive Rice parameters, e.g., ricePar. In some examples, video encoding device 104 and / or video decoding device 112 may determine (e.g., calculate, compute, etc.) a weighted average based on Rice information obtained from neighboring transform coefficients (e.g., riceParTemplate, via a template-based method) and historical Rice parameter information (e.g., riceParHistory, via a history-based method). For example, video encoding device 104 and / or video decoding device 112 may determine a weighted average based on Rice information obtained from neighboring transform coefficients and historical Rice parameter information using the following equation:

[0155]

number

[0156] In some cases, one or more of the weights w1 and w2 of the weighted average may depend on the spatial location of the corresponding coefficient within the currently decoded TU. In some examples, the weighted average may be an exponentially weighted moving average.

[0157]

[0152] Figure 5 illustrates an example of determining historical Rice parameter information and / or historical Rice parameter values ​​based on previously decoded TUs. A series of TUs are shown in a grid 500. The bottom-right TU 510 is the currently decoded TU (e.g., where historical Rice parameter information may be used to derive Rice parameters for individual samples of the currently decoded TU). The remaining TUs 551-557 are previously decoded TUs from which historical Rice parameter information may be calculated. Previously decoded TUs 551-557 are labeled with the time step at which each TU was decoded; e.g., TU 551 was decoded one step ago, TU 552 was decoded two steps ago, TU 553 was decoded three steps ago, etc.

[0158] For each given TU among the previously decoded TUs 551-557, the first non-zero transform coefficient decoded for that given TU is accumulated in the history counter 520. In some examples, the value accumulated in the history counter 520 may be the magnitude of the first non-zero transform coefficient itself, the magnitude of the decoded Rice parameter of the first non-zero transform coefficient, and / or the binary code length (e.g., in bits) of the coefficient or Rice parameter. As shown, the history counter 520 may apply a weight w to each accumulated value R, for example, to implement a weighted sum. From the weighted sum, a weighted average and / or an exponentially weighted moving average may be calculated for the historical Rice parameter values. In some cases, the weight w may be set equal to 1, in which case the history counter 520 implements a sum and an arithmetic mean may be calculated for the historical Rice parameter values.

[0159] In some examples, video encoding device 104 and / or video decoding device 112 may determine the weight w based on the spatial location of the first non-zero transform coefficient in a particular one of previously decoded TUs 551-557 that is used to obtain value R. The spatial location may correspond to one of the classifications C1-C4 discussed above with respect to FIG. 4. The weight w may be a value between 0 and 1, and / or may be an integer value such as 1, 2, 3, etc.

[0160] The value R extracted from the first non-zero transform coefficient of each previously decoded TU 551-557 is used as an update to the history counter 520 and may be referred to as a history update or history update value. The cumulative history update counter maintained by the history counter 520 thus represents a cumulative history sum (or a weighted sum if w is not equal to 1) across the series of previously decoded TUs 551-557. In some examples, the history counter 520 may be initialized to 0 or another starting value at the start of a CTU and / or slice, each of which may contain multiple TUs.

[0161] Based on the accumulated history values ​​in history counter 520, optimal historical Rice parameter values ​​may be used to implement the history-based Rice derivation described herein in current TU 510. For example, as described above, an arithmetic average or an exponentially weighted moving average may be obtained from history counter 520 (or calculated based on one or more values ​​obtained from history counter 520) and used as the historical Rice parameter value. In FIG. 5, connector arrows flow from the output of history counter 520 to two areas of current TU 510, such that historical Rice parameter values ​​from history counter 520 may be utilized to derive Rice parameters for samples located on either the bottom edge or the right edge of current TU 510. The reason for this is that in some instances, the bottom and right edges of a given TU (such as current TU 510) contain individual sample locations that are most likely to have one or more unavailable neighboring transform coefficients as defined by the Rice-derived template (see, for example, classifications C2, C3, and C4 in FIG. 4, which are located on the bottom and right edges of TU 400).

[0162]

[0157] Provided below is an example of a technique that may be used by video encoding device 104 and / or video decoding device 112 for aggregation of local neighborhood coefficient information (e.g., obtained within a current TU based on a Rice derivation template) and historical Rice parameter information (e.g., obtained from previously decoded TUs 551-557 via history counter 520). As mentioned above, historical Rice parameter values ​​may be used in template-based Rice derivation when local information of neighboring transform coefficients is not available or is only partially available. Shown below is a pseudo-code example of how the template-based Rice derivation approach may be extended to also provide history-based Rice derivation. Additions to the existing template-based method are indicated by the underlined text (" additionIt is shown by ")". The term histCoef defines an estimated historical conversion coefficient, which has been accumulated in the past, for example, or is expressed for a historical Rice parameter value such as histCoef = 1 << histRiceParam. The terms M and N are estimated weight values, for example, integer values, and in some examples, they can be equal to 2 and 3 respectively.

[0163] [Number]

[0164]

[0158] The systems and techniques described in this specification can apply various techniques to perform history updates. In some examples, the video encoding device 104 and / or the video decoding device 112 can implement the history parameter for Rice derivation as a counter (for example, the history counter 520). In some cases, the video encoding device 104 and / or the video decoding device 112 can utilize a moving average value storage for the decoded conversion coefficients (for example, of the previously decoded TUs 551 - 557) and / or their corresponding Rice parameters. In some examples, instead of using the actual values of the decoded conversion coefficients or Rice parameters, the video encoding device 104 and / or the video decoding device 112 can determine (for example, calculate, compute, etc.) the length of the binary codeword required to represent the decoded conversion coefficient or the corresponding Rice parameter based on an equation such as the following.

[0165] [Number]

[0166] In one example, for each class identified by index riceClass, video encoding device 104 and / or video decoding device 112 may calculate and store a separate history in counter StatCoeff[riceClass] such that different historical Rice parameter values ​​are utilized depending on the location of unavailable neighboring transform coefficients for the current TU. In some cases, during TU decoding, each decoded transform coefficient defined for inclusion in the history update may be represented through a binary code length estimate (e.g., codeLength, as described above). The binary code length estimate may be used in the history update as indicated by the optimal historical Rice parameter value.

[0167]

[0160] For each previously decoded TU 551-557, the number of transform coefficients to be included in the history update for that TU may be given by NUM_HISTORY_UPDATE. In some examples, NUM_HISTORY_UPDATE is set equal to 1, and only the first non-zero transform coefficient from each previously decoded TU is utilized. However, NUM_HISTORY_UPDATE may also be set to a value such as 2 or 3, in which case the first two or first three non-zero transform coefficients, respectively, should be used for each previously decoded TU.

[0168]

[0161] The number of decoded transform coefficients (e.g., equal to NUM_HISTORY_UPDATE) may be used to update history observations maintained in one or more history counters. In some examples, the history observations may be stored and maintained by a history counter, such as history counter 520. Separate counters may be used in the history update process, where one counter (e.g., collectStatCoeff) maintains a cumulative total of code lengths and another counter (e.g., counterCollectStatCoeff) maintains a cumulative total of the number of coefficients or separate entries provided to the history update process, as follows:

[0169]

number

[0170]

[0162] After the number of samples NUM_HISTORY_UPDATE defined for the history update of the current class and / or current TU are parsed as described above, the global history counter StatCoeff may be updated through a linear model (e.g., a weighted moving average or an exponentially weighted moving average) as follows:

[0171]

number

[0172]

[0163] In some examples, the parameters of the above linear models may be selected as power-of-two derivatives to enable more efficient implementation of low-complexity multiplication and / or division operations.

[0173] In some examples, NUM_HISTORY_UPDATE may be set equal to 1, meaning that only the first non-zero transform coefficient is parsed from each previously decoded TU and used to update the history counter for determining the optimal history Rice parameter. In this case, the above equation for numCollected simplifies to numCollected=0 (alternatively, the original equation above may be retained to account for cases where no transform coefficients were collected for a given previously decoded TU despite NUM_HISTORY_UPDATE being specified to be equal to 1).

[0174] Continuing with the above example, if NUM_HISTORY_UPDATE is set equal to 1 and numCollected is set equal to 0, then the second equation can be simplified as averageRiceInTU = collectStatCoeff. In other words, when only a single transform coefficient is collected per TU (e.g., the first non-zero transform coefficient is collected), the value averageRiceInTU is the same as the collected value collectStatCoeff for that TU.

[0175] In some examples, weights w3 and w4 may both be set equal to 1, for example, to drop them out of the third equation above for StatCoeff[i][compID]. If both weight values ​​are set to 1, then the update value for StatCoeff is calculated as the average of the history update value just received and the previous StatCoeff value from just before the most recent history update value was received. In some examples, NUM_HISTORY_UPDATE, w3, and w4 may each be set equal to 1.

[0176] In some examples, the history counter may be maintained throughout a particular region of a decoded picture, e.g., a full picture, a slice, a tile, a group of CTUs, or a single CTU that is typically reset at the beginning of a group of CTUs. At the beginning of each new region that is decoded, the history counter may be reset to 0 or otherwise initialized to some predetermined starting value.

[0177]

[0168] In examples where the history counter is initialized with a default value at the start of each new region, in some cases the default value may be tabulated and provided to the decoder as side information, signaled through or using the coded bitstream (e.g., at the slice level), provided through a special update signaling mechanism, and / or derived at the decoder side from the bit depth, quantization parameters, or other syntax elements.

[0178]

[0169] In some examples, one or more aspects of the history update process for Rice parameter derivation described herein (e.g., update rate, moving average parameters or weights, etc.) may be made dependent on one or more of block size, block dimension ratio, coding mode (e.g., intra-prediction or inter-prediction), slice type, and / or signaled syntax elements related to decoding.

[0179]

[0170] Figure 6 is a flowchart illustrating an example of a process 600 for processing image and / or video data. At block 602, the process 600 may include obtaining a transform block, where the transform block includes a plurality of samples. In some examples, the transform block may be a coded or decoded transform block. In some examples, the transform block may be a transform unit (TU). In some cases, the transform block may be the same as or similar to one or more of the transform blocks 320, 330, and 340 shown in Figure 3.

[0180] At block 604, process 600 includes determining one or more parameters (e.g., Rice parameters) for the plurality of samples at least in part by analyzing a local neighborhood of the current sample of the plurality of samples. In some cases, block 604 may include scanning a transform block, which may include analyzing a local neighborhood of the current sample of the plurality of samples. In some examples, the local neighborhood of the current sample may be located within the same transform block as the current sample. For example, the local neighborhood may be given by the boundaries of the three transform blocks 320, 300, and 340 shown for the current sample 302 in FIG. 3 .

[0181] In some cases, analyzing the local neighborhood may be performed by comparing the local neighborhood to a template support area. The template support area may be obtained as a parameter derivation template, such as a Rice parameter derivation template (e.g., used to perform template and lookup table-based Rice parameter derivation). In some aspects, one or more parameters (e.g., Rice parameters) may be determined in the context of high bit-depth coding, which may more than usual encounter shortcomings of existing Rice parameter derivation techniques based on lookup tables.

[0182] At block 606, process 600 includes determining that the number of neighboring transform coefficients of the current sample is less than a threshold amount. The determination may be based at least in part on a local neighborhood analysis (e.g., as described above with respect to block 604). In some examples, the threshold amount may be the same as the number of neighboring transform coefficients included in a parameter derivation template (e.g., a Rice parameter derivation template).

[0183] In one illustrative example, the threshold amount may be equal to 5, which is the number of neighboring transform coefficients included in the illustrative template for Rice parameter derivation shown in Figure 2. In some examples, the threshold amount may be greater than or less than 5, and the Rice parameter derivation template may include a greater or lesser number of neighboring coefficients than shown in Figure 2.

[0184]

[0175] In some cases, a determination that the number of neighboring transform coefficients of the current sample is less than a threshold amount may be used to determine that the template support area extends outside the boundary of the transform block. For example, if the number of neighboring transform coefficients available for the current sample is less than a threshold number of transform coefficients included in a parameter derivation template (e.g., a Rice parameter derivation template), the template support area may be determined to extend at least partially outside the boundary of the transform block (e.g., transform block 340 is shown in FIG. 3 as having only one available neighboring transform coefficient 316 within its boundary). In some cases, if the number of neighboring transform coefficients available for the current sample is zero, the template support area may be determined to extend completely outside the boundary of the transform block (e.g., transform block 320 is shown in FIG. 3 as having zero available neighboring transform coefficients within its boundary).

[0185] At block 608, process 600 includes obtaining a history parameter value (e.g., a history Rice parameter value) determined from one or more previously decoded transform blocks. In some examples, the history parameter value may be obtained in response to a determination at block 606 that the number of available neighboring transform coefficients in the transform block is less than a threshold number of transform coefficients included in the Rice-derived template. In some cases, the history parameter value (e.g., the history Rice parameter value) may be dynamically determined at block 608. In some examples, the history parameter value (e.g., the history Rice parameter value) may be obtained or retrieved from a history counter (e.g., history counter 520 shown in FIG. 5) that maintains a weighted sum by accumulating values ​​determined for previously decoded transform blocks or TUs.

[0186] In some examples, a historical parameter value (e.g., a historical Rice parameter value) may be determined from one or more previously decoded transform blocks by applying a weight w to each accumulated value R using a history counter to implement a weighted sum. In some cases, the weighted sum may be used to calculate a weighted average and / or an exponentially weighted moving average, which may then be used as the historical parameter value (e.g., a historical Rice parameter value) obtained in block 608. In some cases, the weight w may be determined based at least in part on the spatial location of the first non-zero transform coefficient in a given previously decoded transform block. In some aspects, the spatial location used to determine the weight w may correspond to one of classifications C1-C4 as shown in FIG. 4. In some aspects, the weight w may be a value between 0 and 1 and / or may be an integer value. In some examples, a history parameter value (e.g., a history Rice parameter value) may be calculated by updating a history counter until the end of the CTU or slice is reached, at which time the history counter (and history Rice parameter value) may be initialized to 0 or some other starting value, and the history update process is repeated.

[0187] At block 610, process 600 includes determining a parameter (e.g., a Rice parameter) for the current sample. Process 600 may determine the parameter (e.g., a Rice parameter) based at least in part on the historical parameter value (e.g., the historical Rice parameter value) obtained at block 608, as described above. In some examples, the historical parameter value (e.g., the historical Rice parameter value) may be used to replace each unavailable neighboring transform coefficient when a template-based parameter derivation technique (e.g., a template-based Rice parameter derivation technique) is utilized. When the template-based neighboring transform coefficients are only partially unavailable, the Rice parameter may be determined based on the sum of the available neighboring transform coefficients and N times the historical parameter value (e.g., the historical Rice parameter value), where N is equal to the number of unavailable neighboring transform coefficients (e.g., as may be determined at block 604).

[0188] At block 612, process 600 includes decoding the current sample based on the determined parameters of the current sample. For example, as described herein, process 600 may perform entropy decoding (e.g., using entropy decoding unit 80 described below with respect to FIG. 9) to decode the current sample based on the parameters. In one example, decoding device 112 may decode the current sample at least in part by decoding a syntax element indicating the current sample based on the determined parameters. In another example, decoding device 112 may decode the current sample at least in part by decoding a Golomb-Rice code using the determined parameters.

[0189]

[0180] Figure 7 is a flow chart illustrating an example of a process 700 for processing image and / or video data. At block 702, process 700 may include obtaining a transform block. In some examples, the transform block may be a coded or decoded transform block. In some examples, the transform block may be a transform unit (TU). In some cases, the transform block may be the same as or similar to one or more of the transform blocks 320, 330, and 340 shown in Figure 3.

[0190] At block 704, process 700 may include determining one or more non-zero decoded transform coefficients based at least in part on the analysis of the transform block. In some cases, the analysis of the transform block may be performed by scanning the transform block. For example, scanning the transform block may be performed in a reverse scan order (e.g., where the reverse scan order starts from the bottom-right sample of the transform block or TU). Scanning may continue until at least the first non-zero decoded transform coefficient is located. If more than one non-zero decoded transform coefficient is to be determined, scanning may continue until a predetermined amount of non-zero decoded transform coefficients is determined. In some examples, when a non-zero decoded transform coefficient is encountered during the scanning process, the non-zero value may be stored in a buffer or counter.

[0191] At block 706, process 700 may include determining a history update value for the transform block based at least in part on one or more non-zero decoded transform coefficients. In one illustrative example, the history update value may be determined from the first non-zero transform coefficient obtained when analyzing (e.g., scanning) the transform block at block 704. In some cases, the history update value for a given transform block may be equal to the value of the first non-zero decoded transform coefficient obtained when scanning the given transform block. In some examples, the history update value for the transform block is determined based on all of the non-zero decoded transform coefficients of the transform block. In some cases, the history update value is determined at least in part by averaging all of the non-zero decoded transform coefficients of the transform block.

[0192]

[0183] In some examples, the history update value may be stored in a history counter (e.g., history counter 520 shown in FIG. 5) that maintains a weighted sum by accumulating history update values ​​determined for previously decoded transform blocks.

[0193] At block 708, process 700 may include updating the existing history parameter values ​​at least in part by combining the history update values ​​of the transformation block with existing history parameter values ​​(e.g., existing history Rice parameter values). In some aspects, combining the history update values ​​of the transformation block with the existing history parameter values ​​may include averaging the history update values ​​of the transformation block with the existing history parameter values. In some cases, the existing history parameter values ​​are existing history Rice parameter values.

[0194] In some aspects, combining the historical update values ​​of the transform block with the existing historical parameter values ​​may include determining an exponentially weighted moving average between the historical update values ​​of the transform block and the existing historical parameter values. In some cases, the process 700 may include assigning a first weight to the historical update values ​​of the transform block and a second weight to the existing historical parameter values. In such cases, determining the exponentially weighted moving average is based at least in part on the first weight and the second weight.

[0195] In some aspects, the history update value of the transform block is determined based on the first non-zero decoded transform coefficient determined in the analysis of the transform block. In some cases, the first non-zero decoded transform coefficient is determined based on a run scan order of the reverse transform block. In some cases, the history update value of the transform block is determined at least in part by determining the binary code length of the first non-zero decoded transform coefficient.

[0196] In some aspects, the transform block and the previously analyzed transform block are associated with a first slice. In some cases, existing history parameter values ​​are iteratively updated based on successive history update values ​​determined for successively analyzed transform blocks associated with the same slice. In some examples, process 700 includes initializing the existing history parameter values ​​to predetermined values. The initialization is performed before analyzing the first transform block of the first slice and determining the history update values ​​for the first transform block.

[0197] For example, the existing history parameter values ​​(e.g., existing history Rice parameter values) may be based at least in part on a set of non-zero decoded transform coefficients determined from a set of previously analyzed (e.g., previously scanned) transform blocks. In some examples, the existing history parameter values ​​(e.g., existing history Rice parameter values) may be determined from one or more previously decoded transform blocks by applying a weight w to each accumulated value R using a history counter, such as to implement or determine a weighted sum.

[0198] In some cases, the weighted sum may be used to calculate a weighted average and / or an exponentially weighted moving average. In one illustrative example, the weight w may be set equal to 1 for each accumulated value. In some cases, the weight w may be determined based at least in part on the spatial location of the first non-zero transform coefficient in a given previously decoded transform block. In some aspects, the spatial location used to determine the weight w may correspond to one of classifications C1-C4 as shown in FIG. 4. In some aspects, the weight w may be a value between 0 and 1 and / or may be an integer value. In some examples, the history Rice parameter value may be calculated by updating a history counter until the end of a CTU or slice is reached, at which time the history counter (and the history Rice parameter value) may be initialized to 0 or some other starting value, and the history update process is repeated.

[0199] At block 710, process 700 includes decoding at least one sample of the transform block based on existing history parameter values ​​or updated existing history parameter values. For example, as described herein, process 700 may perform entropy decoding (e.g., using entropy decoding unit 80 described below with respect to FIG. 9) to decode the current sample based on the existing history parameter values ​​or updated existing history parameter values. In one example, decoding device 112 may decode the current sample at least in part by decoding a syntax element indicating the at least one sample based on the existing history parameter values ​​or updated existing history parameter values. In another example, decoding device 112 may decode the current sample at least in part by decoding a Golomb-Rice code using the existing history parameter values ​​or updated existing history parameter values.

[0200] In some aspects, a process for encoding video data may include obtaining a transform block including a plurality of samples. The process may include determining one or more parameters for the plurality of samples at least in part by analyzing a local neighborhood of a current sample of the plurality of samples. The process may further include determining, at least in part, that a number of neighboring transform coefficients of the current sample is less than a threshold amount based at least in part on the analysis of the local neighborhood. In some cases, the process may determine that the number of neighboring transform coefficients is less than a threshold amount based at least in part on identifying one or more unavailable neighboring transform coefficients for the current sample. In such cases, the one or more unavailable neighboring transform coefficients may be associated with locations outside the transform block. In some examples, the process may include obtaining a location of the current sample within the transform block, comparing the location of the current sample to a width of the transform block, a height of the transform block, or a width and height of the transform block, and identifying one or more unavailable neighboring transform coefficients based at least in part on the comparison. In some cases, to determine that the number of neighboring transform coefficients is less than a threshold amount, the process may include determining that a horizontal component of the current sample location is within a first distance of the width of the transform block, and determining that a vertical component of the current sample location is within a second distance of the height of the transform block.

[0201] The process of encoding video data may further include obtaining historical parameter values ​​determined from one or more previously encoded transform blocks. The process of encoding video data may further include determining parameters for a current sample based at least in part on the historical parameter values. In some examples, the one or more parameters for the plurality of samples include one or more Rice parameters, the historical parameter values ​​are historical Rice parameter values, and the parameters determined for the current sample are Rice parameters of the current sample.

[0202] In some examples, a process for encoding video data may include determining a parameter of a current sample based on a first integer multiple of a historical parameter value, based at least in part on a determination that the number of neighboring transform coefficients is zero. In some aspects, the process may determine the parameter of the current sample at least in part by providing the first integer multiple of the historical parameter value as an input to a lookup table that maps between inputs and parameters. In some cases, the first integer multiple and the threshold amount are the same value. In some aspects, the process may include determining a parameter of the current sample based on a second integer multiple of the historical parameter value and a sum of the neighboring transform coefficients, based at least in part on a determination that the number of neighboring transform coefficients is greater than zero. In such aspects, the second integer multiple is less than the first integer multiple. Further, in such aspects, the process may determine the parameter of the current sample at least in part by providing the second integer multiple of the summed historical parameter value and the sum of the neighboring transform coefficients as an input to a lookup table that maps between inputs and parameters.

[0203] In some examples, the plurality of samples are associated with a transform block sample type. For example, the transform block sample type may include luma samples or chroma samples. In some cases, the transform block sample type is the same as the sample type associated with one or more previously decoded transform blocks from which the historical parameter values ​​are determined.

[0204] In some aspects, the history parameter value is determined based at least in part on a first non-zero decoded transform coefficient obtained from each of one or more previously coded transform blocks. In some examples, the process may include determining a binary code length of each first non-zero decoded transform coefficient obtained from each of the one or more previously coded transform blocks. In some cases, the history parameter value is determined as an exponentially weighted moving average of the binary code lengths determined for the first non-zero coded transform coefficient of each of the one or more previously coded transform blocks.

[0205]

[0196] The process may further include generating a bitstream based on the determined parameters of the current sample. For example, the encoding device 104 (e.g., using the entropy encoding unit 56) may generate a bitstream based on the determined parameters (e.g., Rice parameters).

[0206] In some examples, a process for encoding video data is provided. The process may include obtaining a transform block. The process may further include determining one or more non-zero coded transform coefficients based at least in part on an analysis of the transform block. The process may include determining a history update value for the transform block based at least in part on the one or more non-zero coded transform coefficients.

[0207] A process for encoding video data may include determining a history update value for a transform block based on a first non-zero coded transform coefficient determined in an analysis of the transform block. In some examples, the process may include determining the first non-zero coded transform coefficient based on a run scan order of the backward transform block. In some cases, the process may include determining the history update value for the transform block at least in part by determining a binary code length of the first non-zero coded transform coefficient. In some cases, the process may include determining the history update value for the transform block based on all of the non-zero coded transform coefficients of the transform block. In some examples, the process may include determining the history update value at least in part by averaging all of the non-zero coded transform coefficients of the transform block.

[0208] The process of encoding video data may further include updating existing history parameter values ​​at least in part by combining (e.g., averaging or otherwise combining) the history update values ​​of the transform block with existing history parameter values. In some aspects, the existing history parameter values ​​are existing history Rice parameter values. The existing history parameter values ​​are based at least in part on a set of non-zero coded transform coefficients determined from a set of previously analyzed transform blocks. In some aspects, to update the existing history parameter values, the process may include determining an exponentially weighted moving average between the history update values ​​of the transform block and the existing history parameter values. For example, in some cases, the process may include assigning a first weight to the history update values ​​of the transform block and a second weight to the existing history parameter values, and determining the exponentially weighted moving average based at least in part on the first weight and the second weight.

[0209] In some aspects, the transform block and the previously analyzed transform block are associated with a first slice. The process may further include iteratively updating existing history parameter values ​​based on successive history update values ​​determined for successively analyzed transform blocks associated with the same slice. In some cases, the process may include initializing the existing history parameter values ​​to predetermined values. In some examples, the process may perform the initialization before analyzing the first transform block of the first slice and determining the history update values ​​for the first transform block.

[0210] The process of encoding the video data may further include generating a bitstream based on existing historical parameter values ​​or updated existing historical parameter values. For example, encoding device 104 (e.g., using entropy encoding unit 56) may generate a bitstream based on the determined parameters (e.g., Rice parameters).

[0211] In some implementations, the processes (or methods) described herein may be performed by a computing device or apparatus, such as the system 100 shown in FIG. 1. For example, the processes may be performed by the encoding device 104 shown in FIGS. 1 and 8, by another video source-side device or video transmission device, by the decoding device 112 shown in FIGS. 1 and 9, and / or by another client-side device, such as a player device, a display, or any other client-side device. In some cases, the computing device or apparatus may include a processor, microprocessor, microcomputer, or other components of a device configured to perform the steps of the processes described herein. In some examples, the computing device or apparatus may include a camera configured to capture video data (e.g., a video sequence) including video frames. In some examples, the camera or other capture device that captures the video data is separate from the computing device, in which case the computing device receives or acquires the captured video data. The computing device may further include a network interface configured to communicate the video data. The network interface may be configured to communicate Internet Protocol (IP)-based data or other types of data. In some examples, the computing device or apparatus may include a display for displaying output video content, such as sample pictures of a video bitstream.

[0212]

[0203] A process may be described in terms of logical flow diagrams, whose operations represent sequences of actions that may be implemented in hardware, computer instructions, or a combination thereof. In the context of computer instructions, the operations represent computer-executable instructions stored on one or more computer-readable storage media that, when executed by one or more processors, perform the recited operations. Generally, computer-executable instructions include routines, programs, objects, components, data structures, etc. that perform particular functions or implement particular data types. The order in which the operations are described should not be construed as a limitation, and any number of the described operations may be combined in any order and / or in parallel to implement a process.

[0213]

[0204] Furthermore, the process may be performed under the control of one or more computer systems configured of executable instructions and may be implemented as code (e.g., executable instructions, one or more computer programs, or one or more applications) that collectively execute on one or more processors, by hardware, or a combination thereof. As noted above, the code may be stored on a computer-readable or machine-readable storage medium, for example, in the form of a computer program comprising a plurality of instructions executable by one or more processors. The computer-readable or machine-readable storage medium may be non-transitory.

[0214] The coding techniques described herein may be implemented in an exemplary video encoding and decoding system (e.g., system 100). In some examples, the system includes a source device that provides encoded video data to be subsequently decoded by a destination device. In particular, the source device provides the video data to the destination device via a computer-readable medium. The source and destination devices may comprise any of a wide range of devices, including desktop computers, notebook (i.e., laptop) computers, tablet computers, set-top boxes, telephone handsets such as so-called "smart" phones, so-called "smart" pads, televisions, cameras, display devices, digital media players, video game consoles, video streaming devices, etc. In some cases, the source and destination devices may be equipped for wireless communication.

[0215]

[0206] The destination device may receive the encoded video data to be decoded via a computer-readable medium. The computer-readable medium may comprise any type of medium or device capable of moving encoded video data from a source device to a destination device. In one example, the computer-readable medium may comprise a communication medium for enabling the source device to transmit the encoded video data directly to the destination device in real time. The encoded video data may be modulated according to a communication standard, such as a wireless communication protocol, and transmitted to the destination device. The communication medium may comprise 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 the source device to the destination device.

[0216]

[0207] In some examples, the encoded data may be output from the output interface to a storage device. Similarly, the encoded data may be accessed from the storage device by the input interface. The storage device may include any of a variety of distributed or locally accessed data storage media, such as a hard drive, Blu-ray disc, DVD, CD-ROM, flash memory, volatile or non-volatile memory, or any other suitable digital storage medium for storing encoded video data. In further examples, the storage device may correspond to a file server or another intermediate storage device that may store the encoded video generated by the source device. The destination device may access the stored video data from the storage device via streaming or download. The file server may be any type of server capable of storing the encoded video data and transmitting the encoded video data to the destination device. Exemplary file servers include a web server (e.g., for a website), an FTP server, a network-attached storage (NAS) device, or a local disk drive. The destination device may access the encoded video data through any standard data connection, including an Internet connection. This may include a wireless channel (e.g., a Wi-Fi connection), a wired connection (e.g., DSL, cable modem, etc.), or a combination of both, that is suitable for accessing the encoded video data stored on the file server. The transmission of the encoded video data from the storage device may be a streaming transmission, a download transmission, or a combination thereof.

[0217] The techniques of this disclosure are not necessarily limited to wireless applications or settings. The techniques may be applied to video coding supporting any of a variety of multimedia applications, such as over-the-air television broadcast, cable television transmission, satellite television transmission, Internet streaming video transmission such as Dynamic Adaptive Streaming over HTTP (DASH), digital video encoded on a data storage medium, decoding of digital video stored on a data storage medium, or other applications. In some examples, a system may be configured to support one-way or two-way video transmission to support applications such as video streaming, video playback, video broadcasting, and / or video telephony.

[0218]

[0209] In one example, the source device includes a video source, a video encoder, and an output interface. The destination device may include an input interface, a video decoder, and a display device. The video encoder of the source device may be configured to apply the techniques disclosed herein. In other examples, the source device and destination device may include other components or arrangements. For example, the source device may receive video data from an external video source, such as an external camera. Similarly, the destination device may interface with an external display device rather than including an integrated display device.

[0219] The above exemplary system is merely an example. Techniques for processing video data in parallel may be implemented by any digital video encoding and / or decoding device. Generally, the techniques of this disclosure are implemented by a video encoding device, but the techniques may also be implemented by a video encoder / decoder, commonly referred to as a "codec." Moreover, the techniques of this disclosure may also be implemented by a video preprocessor. The source device and destination device are merely examples of coding devices, such that the source device generates coded video data for transmission to the destination device. In some examples, the source device and destination device may operate substantially symmetrically, such that each device includes a video encoding component and a video decoding component. Thus, an exemplary system may support one-way or two-way video transmission between video devices, e.g., for video streaming, video playback, video broadcasting, or video telephony.

[0220] The video source may include a video capture device such as a video camera, a video archive containing previously captured video, and / or a video feed interface for receiving video from a video content provider. As a further alternative, the video source may generate computer graphics-based data as the source video, or a combination of live, archived, and computer-generated video. In some cases, when the video source is a video camera, the source and destination devices may form a so-called camera phone or video phone. However, as mentioned above, the techniques described in this disclosure may be applicable to video coding generally and may be applied to wireless and / or wired applications. In each case, the captured video, pre-captured video, or computer-generated video may be encoded by a video encoder. The encoded video information may then be output onto a computer-readable medium by an output interface.

[0221] As mentioned, computer-readable media may include transient media, such as a wireless broadcast or wired network transmission, or storage media (i.e., non-transitory storage media), such as a hard disk, flash drive, compact disc, digital video disc, Blu-ray disc, or other computer-readable medium. In some examples, a network server (not shown) may receive encoded video data from a source device, e.g., via a network transmission, and provide the encoded video data to a destination device. Similarly, a computing device of a media production facility, such as a disc stamping facility, may receive encoded video data from a source device and generate a disc containing the encoded video data. Thus, computer-readable media may be understood to include one or more computer-readable media of various forms in various examples.

[0222]

[0213] The input interface of the destination device receives information from a computer-readable medium. The information on the computer-readable medium may include syntax information, including syntax elements that describe characteristics and / or processing of blocks and other coded units, e.g., groups of pictures (GOPs), defined by a video encoder and used by a video decoder. The display device displays the decoded video data to a user and may comprise any of a variety of 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. Various embodiments of the present application have been described.

[0223] Specific details of encoding device 104 and decoding device 112 are shown in Figures 8 and 9, respectively. Figure 8 is a block diagram illustrating an example encoding device 104 that may implement one or more of the techniques described in this disclosure. Encoding device 104 may, for example, generate a syntax structure described herein (e.g., a syntax structure for a VPS, SPS, PPS, or other syntax element). Encoding device 104 may perform intra-predictive and inter-predictive coding of video blocks within video slices. As previously described, intra-coding relies at least in part on spatial prediction to reduce or remove spatial redundancy within a given video frame or picture. Inter-coding relies at least in part on temporal prediction to reduce or remove temporal redundancy within adjacent or surrounding frames of a video sequence. Intra-mode (I-mode) may refer to any of several spatial-based compression modes. Inter-mode, such as unidirectional prediction (P-mode) or bi-prediction (B-mode), may refer to any of several temporal-based compression modes.

[0224] Encoding device 104 includes partition unit 35, prediction processing unit 41, filter unit 63, picture memory 64, adder 50, transform processing unit 52, quantization unit 54, and entropy coding unit 56. Prediction processing unit 41 includes motion estimation unit 42, motion compensation unit 44, and intra-prediction processing unit 46. For video block reconstruction, encoding device 104 also includes inverse quantization unit 58, inverse transform processing unit 60, and adder 62. Filter unit 63 is intended to represent one or more loop filters, such as a deblocking filter, an adaptive loop filter (ALF), and a sample adaptive offset (SAO) filter. Although filter unit 63 is shown in FIG. 8 as being an in-loop filter, in other configurations, filter unit 63 may be implemented as a post-loop filter. Post-processing device 57 may perform additional processing on the encoded video data generated by encoding device 104. The techniques of this disclosure may, in some cases, be implemented by encoding device 104. However, in other cases, one or more of the techniques of this disclosure may be implemented by post-processing device 57.

[0225] As shown in FIG. 8, encoding device 104 receives video data, and partitioning unit 35 partitions the data into video blocks. Partitioning may also include partitioning into slices, slice segments, tiles, or other larger units, as well as video block partitioning, for example, according to a quadtree structure of LCUs and CUs. Encoding device 104 generally refers to components that encode video blocks within a video slice to be coded. A slice may be divided into multiple video blocks (and possibly into sets of video blocks called tiles). Prediction processing unit 41 may select one of multiple possible coding modes, such as one of multiple intra-predictive coding modes or one of multiple inter-predictive coding modes, for a current video block based on error results (e.g., coding rate, distortion level, etc.). Prediction processing unit 41 may provide the resulting intra-coded or inter-coded block to adder 50 to generate residual block data and to adder 62 to reconstruct a coding block for use as a reference picture.

[0226]

[0217] Intra-prediction processing unit 46 within prediction processing unit 41 may perform intra-predictive coding of the current video block relative to one or more neighboring blocks in the same frame or slice as the current block to be coded to provide spatial compression. Motion estimation unit 42 and motion compensation unit 44 within prediction processing unit 41 perform inter-predictive coding of the current video block relative to one or more predictive blocks in one or more reference pictures to provide temporal compression.

[0227] Motion estimation unit 42 may be configured to determine an inter-prediction mode for a video slice according to a predetermined pattern for the video sequence. The predetermined pattern may designate the video slices in the sequence as P slices, B slices, or GPB slices. Motion estimation unit 42 and motion compensation unit 44 may be highly integrated but are shown separately for conceptual purposes. Motion estimation performed by motion estimation unit 42 is the process of generating motion vectors that estimate motion for video blocks. A motion vector may indicate, for example, the displacement of a prediction unit (PU) of a video block in a current video frame or picture relative to a predictive block in a reference picture.

[0228]

[0219] A predictive block is a block that is found to closely match a PU of a video block to be coded, in terms of pixel differences, which may be determined by sum of absolute differences (SAD), sum of squared differences (SSD), or other difference metrics. In some examples, encoding device 104 may calculate values ​​for sub-integer pixel locations of reference pictures stored in picture memory 64. For example, encoding device 104 may interpolate values ​​at quarter-pixel locations, eighth-pixel locations, or other fractional-pixel locations of reference pictures. Thus, motion estimation unit 42 may perform motion searches for full-pixel and fractional-pixel locations and output motion vectors with fractional-pixel precision.

[0229]

[0220] Motion estimation unit 42 calculates a motion vector for a PU of a video block in an inter-coded slice by comparing the position of the PU with the position of a predictive block of a reference picture. The reference picture may be selected from a first reference picture list (list 0) or a second reference picture list (list 1), each of which identifies one or more reference pictures stored in picture memory 64. Motion estimation unit 42 sends the calculated motion vector to entropy encoding unit 56 and motion compensation unit 44.

[0230]

[0221] Motion compensation performed by motion compensation unit 44 may involve fetching or generating a predictive block based on a motion vector determined by motion estimation, possibly performing interpolation to sub-pixel precision. Upon receiving a motion vector for a PU of a current video block, motion compensation unit 44 may locate the predictive block to which the motion vector points in a reference picture list. Encoding device 104 forms a residual video block by subtracting pixel values ​​of the predictive block from pixel values ​​of the current video block being coded to form pixel difference values. The pixel difference values ​​form residual data for the block and may include both luma and chroma difference components. Adder 50 represents one or more components that perform this subtraction operation. Motion compensation unit 44 may also generate syntax elements associated with the video block and the video slice for use by decoding device 112 in decoding the video blocks of the video slice.

[0231]

[0222] Intra-prediction processing unit 46 may intra-predict the current block as an alternative to the inter-prediction performed by motion estimation unit 42 and motion compensation unit 44, as described above. In particular, intra-prediction processing unit 46 may determine an intra-prediction mode to use to encode the current block. In some examples, intra-prediction processing unit 46 may encode the current block using various intra-prediction modes, e.g., during separate encoding passes, and intra-prediction processing unit 46 may select an appropriate intra-prediction mode to use from the tested modes. For example, intra-prediction processing unit 46 may calculate rate-distortion values ​​using rate-distortion analysis for the various tested intra-prediction modes and select the intra-prediction mode with the best rate-distortion characteristics among the tested modes. The rate-distortion analysis generally determines the amount of distortion (or error) between the coded block and the original uncoded block coded to generate the coded block, as well as the bitrate (i.e., number of bits) used to generate the coded block. Intra-prediction processing unit 46 may calculate ratios from the distortions and rates for the various coding blocks to determine which intra-prediction mode exhibits the best rate-distortion value for the block.

[0232]

[0223] In either case, after selecting an intra-prediction mode for a block, intra-prediction processing unit 46 may provide information indicating the selected intra-prediction mode for the block to entropy coding unit 56. Entropy coding unit 56 may encode the information indicating the selected intra-prediction mode. Encoding device 104 may include in the transmitted bitstream configuration data definitions of coding contexts for various blocks, as well as an indication of the most probable intra-prediction mode, intra-prediction mode index table, and modified intra-prediction mode index table to use for each of the contexts. The bitstream configuration data may include multiple intra-prediction mode index tables and multiple modified intra-prediction mode index tables (also referred to as codeword mapping tables).

[0233] After prediction processing unit 41 generates a predictive block for a current video block via either inter-prediction or intra-prediction, encoding device 104 forms a residual video block by subtracting the predictive block from the current video block. The residual video data in the residual block may be included in one or more TUs and applied to transform processing unit 52. Transform processing unit 52 converts the residual video data into residual transform coefficients using a transform, such as a discrete cosine transform (DCT) or a conceptually similar transform. Transform processing unit 52 may convert the residual video data from the pixel domain to a transform domain, such as the frequency domain.

[0234]

[0225] Transform processing unit 52 may send the resulting transform coefficients to quantization unit 54. Quantization unit 54 quantizes the transform coefficients to further reduce the bit rate. The quantization process may reduce the bit depth associated with some or all of the coefficients. The degree of quantization may be modified by adjusting a quantization parameter. In some examples, quantization unit 54 may then perform a scan of a matrix including the quantized transform coefficients. Alternatively, entropy coding unit 56 may perform the scan.

[0235] After quantization, entropy coding unit 56 entropy codes the quantized transform coefficients. For example, entropy coding unit 56 may implement context-adaptive variable length coding (CAVLC), context-adaptive binary arithmetic coding (CABAC), syntax-based context-adaptive binary arithmetic coding (SBAC), probability interval partitioned entropy (PIPE) coding, or another entropy coding technique. After entropy coding by entropy coding unit 56, the coded bitstream may be transmitted to decoding device 112 or archived for later transmission or retrieval by decoding device 112. Entropy coding unit 56 may also entropy code motion vectors and other syntax elements for the current video slice being coded.

[0236]

[0227] Inverse quantization unit 58 and inverse transform processing unit 60 apply inverse quantization and inverse transform, respectively, to reconstruct the residual block in the pixel domain for later use as a reference block of a reference picture. Motion compensation unit 44 may calculate a reference block by adding the residual block to a predictive block of one of the reference pictures in the reference picture list. Motion compensation unit 44 may also apply one or more interpolation filters to the reconstructed residual block to calculate sub-integer pixel values ​​for use in motion estimation. Adder 62 adds the reconstructed residual block to the motion-compensated predictive block generated by motion compensation unit 44 to generate a reference block for storage in picture memory 64. The reference block may be used as a reference block by motion estimation unit 42 and motion compensation unit 44 to inter-predict blocks in subsequent video frames or pictures.

[0237] 8 represents an example of a video encoder configured to implement the techniques described herein. For example, encoding device 104 may implement any of the techniques described herein, including the processes described herein. In some cases, some of the techniques of this disclosure may also be implemented by post-processing device 57.

[0238] 9 is a block diagram illustrating an exemplary decoding device 112. Decoding device 112 includes entropy decoding unit 80, prediction processing unit 81, inverse quantization unit 86, inverse transform processing unit 88, adder 90, filter unit 91, and picture memory 92. Prediction processing unit 81 includes motion compensation unit 82 and intra-prediction processing unit 84. Decoding device 112 may, in some examples, perform a decoding path that is generally inverse to the encoding path described with respect to encoding device 104 from FIG.

[0239] During the decoding process, decode device 112 receives an encoded video bitstream representing video blocks of encoded video slices and associated syntax elements sent by encoding device 104. In some embodiments, decode device 112 may receive the encoded video bitstream from encoding device 104. In some embodiments, decode device 112 may receive the encoded video bitstream from a network entity 79, such as a server, a media-aware network element (MANE), a video editor / splitter, or other such device configured to implement one or more of the techniques described above. Network entity 79 may or may not include encoding device 104. Some of the techniques described in this disclosure may be implemented by network entity 79 before network entity 79 sends the encoded video bitstream to decode device 112. In some video decoding systems, network entity 79 and decode device 112 may be part of separate devices, while in other cases, the functionality described with respect to network entity 79 may be performed by the same device that comprises decode device 112.

[0240]

[0231] Entropy decoding unit 80 of decoding device 112 entropy decodes the bitstream to generate quantized coefficients, motion vectors, and other syntax elements. Entropy decoding unit 80 forwards the motion vectors and other syntax elements to prediction processing unit 81. Decoding device 112 may receive video slice-level and / or video block-level syntax elements. Entropy decoding unit 80 may process and parse both fixed-length and variable-length syntax elements, such as VPS, SPS, and PPS, or in multiple parameter sets.

[0241] When a video slice is coded as an intra-coded (I) slice, intra-prediction processing unit 84 of prediction processing unit 81 may generate predictive data for video blocks of the current video slice based on the signaled intra-prediction mode and data from previously decoded blocks of the current frame or picture. When a video frame is coded as an inter-coded (i.e., B, P, or GPB) slice, motion compensation unit 82 of prediction processing unit 81 generates predictive blocks for video blocks of the current video slice based on motion vectors and other syntax elements received from entropy decoding unit 80. The predictive blocks may be generated from one of the reference pictures in the reference picture list. Decoding device 112 may construct the reference frame lists, i.e., List 0 and List 1, using a default construction technique based on the reference pictures stored in picture memory 92.

[0242]

[0233] Motion compensation unit 82 determines prediction information for video blocks of the current video slice by parsing the motion vectors and other syntax elements, and uses the prediction information to generate predictive blocks for the current video block being decoded. For example, motion compensation unit 82 may use one or more syntax elements in a parameter set to determine a prediction mode (e.g., intra or inter prediction) used to code the video blocks of the video slice, an inter-prediction slice type (e.g., B slice, P slice, or GPB slice), construction information for one or more reference picture lists for the slice, a motion vector for each inter-coded video block of the slice, an inter-prediction status for each inter-coded video block of the slice, and other information for decoding video blocks in the current video slice.

[0243] Motion compensation unit 82 may also perform interpolation based on an interpolation filter. Motion compensation unit 82 may use the interpolation filter used by encoding device 104 during encoding of the video block to calculate interpolated values ​​for sub-integer pixels of the reference block. In this case, motion compensation unit 82 may determine the interpolation filter used by encoding device 104 from a received syntax element and may use that interpolation filter to generate the predictive block.

[0244]

[0235] Inverse quantization unit 86 inverse quantizes, i.e., dequantizes, the quantized transform coefficients provided in the bitstream and decoded by entropy decoding unit 80. The inverse quantization process may involve the use of quantization parameters calculated by encoding device 104 for each video block in a video slice to determine the degree of quantization, and similarly, the degree of inverse quantization that should be applied. Inverse transform processing unit 88 applies an inverse transform (e.g., an inverse DCT or other suitable inverse transform), an inverse integer transform, or a conceptually similar inverse transform process to the transform coefficients to generate residual blocks in the pixel domain.

[0245] After motion compensation unit 82 generates a predictive block for a current video block based on the motion vector and other syntax elements, decoding device 112 forms a decoded video block by adding a residual block from inverse transform processing unit 88 with the corresponding predictive block generated by motion compensation unit 82. Adder 90 represents one or more components that perform this addition operation. If desired, a loop filter (either within the coding loop or after the coding loop) may also be used to smooth pixel transitions or otherwise improve video quality. Filter unit 91 is intended to represent one or more loop filters, such as a deblocking filter, an adaptive loop filter (ALF), and a sample adaptive offset (SAO) filter. Although filter unit 91 is shown in FIG. 9 as being an in-loop filter, in other configurations, filter unit 91 may be implemented as a post-loop filter. The decoded video blocks in a given frame or picture are then stored in picture memory 92, which stores reference pictures used for subsequent motion compensation. Picture memory 92 also stores decoded video for later presentation on a display device, such as video destination device 122 shown in FIG.

[0246] 9 represents an example of a video decoder configured to implement the techniques described herein. For example, decoding device 112 may implement any of the techniques described herein, including the processes described herein.

[0247]

[0238] As used herein, the term "computer-readable medium" includes, but is not limited to, portable or non-portable storage devices, optical storage devices, and various other media capable of storing, containing, or carrying instruction(s) and / or data. Computer-readable media may include non-transitory media on which data may be stored, which does not include carrier waves and / or transitory electronic signals propagating wirelessly or over wired connections. Examples of non-transitory media may include, but are not limited to, magnetic disks or tapes, optical storage media such as compact discs (CDs) or digital versatile discs (DVDs), flash memory, memory, or memory devices. A computer-readable medium may have stored thereon code and / or machine-executable instructions, which may represent a procedure, a function, a subprogram, a program, a routine, a subroutine, a module, a software package, a class, or any combination of instructions, data structures, or program statements. A code segment may be coupled to another code segment or a hardware circuit by passing and / or receiving information, data, arguments, parameters, or memory contents. Information, arguments, parameters, data, etc. may be passed, forwarded, or transmitted via any suitable means including memory sharing, message passing, token passing, network transmission, etc.

[0248] In some embodiments, computer-readable storage devices, media, and memories may include cable or wireless signals containing bitstreams, etc. However, when stated, non-transitory computer-readable storage media specifically excludes media such as energy, carrier signals, electromagnetic waves, and the signals themselves.

[0249]

[0240] Specific details are provided in the above description to provide a thorough understanding of the embodiments and examples provided herein. However, those skilled in the art will understand that the embodiments may be practiced without these specific details. For clarity of explanation, in some instances, the technology may be presented as including individual functional blocks, including devices, device components, steps or routines in a method implemented in software, or functional blocks comprising a combination of hardware and software. Additional components other than those shown in the figures and / or described herein may be used. For example, circuits, systems, networks, processes, and other components may be shown as components in block diagram form so as not to obscure the embodiments in unnecessary detail. In other instances, well-known circuits, processes, algorithms, structures, and techniques may be shown without unnecessary detail to avoid obscuring the embodiments.

[0250]

[0241] Individual embodiments may be described above as a process or method that is depicted as a flowchart, a flow diagram, a data flow diagram, a structure diagram, or a block diagram. While a flowchart may describe operations as a sequential process, many of the operations may be performed in parallel or simultaneously. Moreover, the order of operations may be rearranged. A process is terminated when its operations are completed but may have additional steps not included in the diagram. A process may correspond to a method, a function, a procedure, a subroutine, a subprogram, etc. When a process corresponds to a function, its termination may correspond to a return of the function to the calling function or the main function.

[0251]

[0242] The processes and methods according to the examples described above may be implemented using computer-executable instructions stored on or otherwise available from a computer-readable medium. Such instructions may include, for example, instructions and data that cause or otherwise configure a general-purpose computer, a special-purpose computer, or a processing device to perform a certain function or group of functions. Portions of the computer resources used may be accessible over a network. The computer-executable instructions may be, for example, binaries, intermediate format instructions such as assembly language, firmware, source code, etc. Examples of computer-readable media that may be used to store instructions, information used, and / or information created during methods according to the described examples include magnetic or optical disks, flash memory, USB devices with non-volatile memory, networked storage devices, etc.

[0252] Devices implementing processes and methods according to these disclosures may include hardware, software, firmware, middleware, microcode, hardware description languages, or any combination thereof, and may take any of a variety of form factors. When implemented in software, firmware, middleware, or microcode, program code or code segments (e.g., a computer program product) to perform the necessary tasks may be stored on a computer-readable or machine-readable medium. A processor may perform the necessary tasks. Typical examples of form factors include laptops, smartphones, mobile phones, tablet devices or other small form-factor personal computers, personal digital assistants, rack-mounted devices, standalone devices, etc. The functionality described herein may also be embodied in peripheral devices or add-in cards. Such functionality may also be implemented on a circuit board among different chips or different processes executing in a single device, as further examples.

[0253]

[0244] The instructions, media for carrying such instructions, computing resources for executing them, and other structures for supporting such computing resources are exemplary means for providing the functionality described in this disclosure.

[0254]

[0245] In the foregoing description, aspects of the present application have been described with reference to specific embodiments thereof, but those skilled in the art will recognize that the present application is not limited thereto. While exemplary embodiments of the present application have been described in detail herein, it should be understood that the inventive concepts may, in some cases, be embodied and employed in various ways, and that the appended claims are intended to include such variations, except as limited by the prior art. Various features and aspects of the applications described above may be used individually or together. Moreover, the embodiments may be utilized in any number of environments and applications other than those described herein without departing from the broader spirit and scope of the present specification. Accordingly, the specification and drawings should be considered illustrative and not restrictive. For purposes of explanation, methods have been described in a particular order. It should be appreciated that in alternative embodiments, methods may be performed in an order different from that described.

[0255]

[0246] Those skilled in the art will appreciate that the less than ("<") and greater than (">") symbols or terminology used herein may be replaced with the less than or equal to ("≦") and greater than or equal to ("≧") symbols, respectively, without departing from the scope of this specification.

[0256]

[0247] When a component is described as being "configured to" perform a certain operation, such configuration may be achieved, for example, by designing electronic circuitry or other hardware to perform the operation, by programming a programmable electronic circuit (e.g., a microprocessor or other suitable electronic circuitry) to perform the operation, or by any combination thereof.

[0257]

[0248] The phrase "coupled to" refers to any component that is physically connected to another component, either directly or indirectly, and / or that is in communication with another component, either directly or indirectly (e.g., connected to the other component via a wired or wireless connection and / or other suitable communication interface).

[0258]

[0249] Claim language or other language reciting "at least one of" a set and / or "one or more" of a set indicates that one member of the set or multiple members of the set (in any combination) satisfies the claim. For example, claim language reciting "at least one of A and B" means A, B, or A and B. As another example, claim language reciting "at least one of A, B, and C" means A, B, C, or A and B, or A and C, or B and C, or A, B, and C. The language "at least one of" a set and / or "one or more" of a set does not limit the set to the items listed in the set. For example, claim language reciting "at least one of A and B" can mean A, B, or A and B, and can further include items not listed in the set of A and B.

[0259]

[0250] The various illustrative logic blocks, modules, circuits, and algorithm steps described in connection with the embodiments disclosed herein may be implemented as electronic hardware, computer software, firmware, or combinations thereof. To clearly illustrate this interchangeability of hardware and software, the various illustrative components, blocks, modules, circuits, and steps have been described above generally in terms of their functionality. Whether such functionality is implemented as hardware or software depends on the particular application and design constraints imposed on the overall system. Those skilled in the art may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the present application.

[0260] The techniques described herein may also be implemented in electronic hardware, computer software, firmware, or any combination thereof. Such techniques may be implemented in any of a variety of devices, such as a general-purpose computer, a wireless communication device handset, or an integrated circuit device having multiple uses, including applications in wireless communication device handsets and other devices. Features described as modules or components may be implemented together in an integrated logic device or separately as discrete but interoperable logic devices. If implemented in software, the techniques may be realized, at least in part, by a computer-readable data storage medium comprising program code including instructions that, when executed, perform, at least in part, one or more of the methods described above. The computer-readable data storage medium may form part of a computer program product, which may include packaging materials. The computer-readable medium may comprise a memory or data storage medium, such as a random access memory (RAM) such as synchronous dynamic random access memory (SDRAM), a read-only memory (ROM), a nonvolatile random access memory (NVRAM), an electrically erasable programmable read-only memory (EEPROM), a FLASH memory, a magnetic or optical data storage medium, or the like. The techniques may additionally or alternatively be realized at least in part by a computer-readable communications medium, such as a propagated signal or radio waves, that carries or communicates program code in the form of instructions or data structures and that can be accessed, read, and / or executed by a computer.

[0261] The program code may be executed by a processor, which may include one or more processors, such as one or more digital signal processors (DSPs), general-purpose microprocessors, application-specific integrated circuits (ASICs), field-programmable logic arrays (FPGAs), or other equivalent integrated or discrete logic circuitry. Such a processor may be configured to perform any of the techniques described in this disclosure. A general-purpose processor may be a microprocessor, but alternatively, the processor may be any conventional processor, controller, microcontroller, or state machine. A processor may also be implemented as a combination of computing devices, e.g., a combination of a DSP and a microprocessor, multiple microprocessors, one or more microprocessors in conjunction with a DSP core, or any other such configuration. Accordingly, the term “processor,” as used herein, may refer to any of the above structures, any combination of the above structures, or any other structure or apparatus suitable for implementing the techniques described herein. Additionally, in some aspects, the functionality described herein may be provided within dedicated software or hardware modules configured for encoding and decoding, or incorporated into a combined video encoder / decoder (CODEC).

[0262]

[0253] Illustrative examples of the present disclosure include the following:

[0263]

[0254] Aspect 1: A method for decoding video data, the method comprising: obtaining a transform block; determining one or more parameters for a plurality of samples at least in part by analyzing a local neighborhood of a current sample among the plurality of samples, the transform block including a plurality of samples; determining, based at least in part on the analysis of the local neighborhood, that a number of neighboring transform coefficients of the current sample is less than a threshold amount; obtaining historical parameter values ​​determined from one or more previously decoded transform blocks; determining parameters for the current sample based at least in part on the historical parameter values; and decoding the current sample based on the determined parameters for the current sample.

[0264]

[0255] Aspect 2: The method of aspect 1, further comprising determining a parameter for the current sample based on a first integer multiple of the historical parameter value based at least in part on a determination that the number of neighboring transform coefficients is 0.

[0265]

[0256] Aspect 3: The method of aspect 2, wherein determining the parameter of the current sample comprises providing a first integer multiple of the historical parameter value as an input to a lookup table that maps between inputs and parameters.

[0266]

[0257] Aspect 4: The method of any of aspects 2 or 3, wherein the first integer multiple and the threshold amount are the same value.

[0267]

[0258] Aspect 5: The method of any of aspects 2 to 4, further comprising determining, at least in part, a parameter of the current sample based on a second integer multiple of the historical parameter value and the sum of the neighboring transform coefficients, based at least in part on a determination that the number of neighboring transform coefficients is greater than 0.

[0268]

[0259] Aspect 6: The method of aspect 5, wherein determining the parameters of the current sample comprises providing a sum of the neighboring transform coefficients and a second integer multiple of the summed historical parameter value as an input to a lookup table that maps between inputs and parameters.

[0269]

[0260] Aspect 7: The method of aspect 6, wherein the second integer multiple is smaller than the first integer multiple.

[0270]

[0261] Aspect 8: The method of any of aspects 1 to 7, wherein determining that the number of neighboring transform coefficients is less than a threshold amount is based at least in part on identifying one or more unavailable neighboring transform coefficients for the current sample.

[0271]

[0262] Aspect 9: The method of aspect 8, further comprising obtaining a location of a current sample within a transform block, comparing the location of the current sample to one or more of a width of the transform block and a height of the transform block, and identifying one or more unavailable neighboring transform coefficients based at least in part on the comparison.

[0272]

[0263] Embodiment 10: The method of embodiment 9, wherein the one or more unavailable neighboring transform coefficients are associated with locations outside the transform block.

[0273]

[0264] Aspect 11: A method of any of aspects 9 or 10, wherein determining that the number of neighboring transform coefficients is less than a threshold amount comprises determining that a horizontal component of the current sample location is within a first distance of the width of the transform block, and determining that a vertical component of the current sample location is within a second distance of the height of the transform block.

[0274]

[0265] Aspect 12: The method of any of aspects 1-11, wherein the plurality of samples are associated with a transform block sample type, and the transform block sample type includes a luma sample or a chroma sample.

[0275]

[0266] Aspect 13: The method of aspect 12, wherein the transform block sample type is the same as a sample type associated with one or more previously decoded transform blocks from which the history parameter values ​​are determined.

[0276]

[0267] Aspect 14: The method of any of aspects 1 to 13, wherein the history parameter value is determined based at least in part on a first non-zero decoded transform coefficient obtained from each of one or more previously decoded transform blocks.

[0277]

[0268] Aspect 15: The method of aspect 14, further comprising determining a binary code length of each first non-zero decoded transform coefficient obtained from each of one or more previously decoded transform blocks.

[0278]

[0269] Aspect 16: The method of aspect 15, wherein the history parameter value is determined as an exponentially weighted moving average of binary code lengths determined for the first non-zero decoded transform coefficient of each of one or more previously decoded transform blocks.

[0279]

[0270] Aspect 17: A method of any of aspects 1 to 16, wherein the one or more parameters for the plurality of samples include one or more Rice parameters, the historical parameter values ​​are historical Rice parameter values, and the parameters determined for the current sample are Rice parameters of the current sample.

[0280]

[0271] Aspect 18: The method of any of aspects 1 to 17, wherein decoding the current sample based on the determined parameters of the current sample comprises decoding a syntax element indicating the current sample based on the determined parameters.

[0281]

[0272] Aspect 19: The method of any of aspects 1 to 18, wherein decoding the current sample based on the determined parameters comprises decoding a Golomb-Rice code using the determined parameters.

[0282]

[0273] Aspect 20: A method for decoding video data, the method comprising: obtaining a transform block; determining one or more non-zero decoded transform coefficients based at least in part on an analysis of the transform block; determining a history update value for the transform block based at least in part on the one or more non-zero decoded transform coefficients; updating an existing history parameter value at least in part by combining the history update value for the transform block with an existing history parameter value; and decoding at least one sample of the transform block based on the existing history parameter value or an updated existing history parameter value based at least in part on a series of non-zero decoded transform coefficients determined from a series of previously analyzed transform blocks.

[0283]

[0274] Aspect 21: The method of aspect 20, wherein combining the history update values ​​of the transform block with the existing history parameter values ​​comprises averaging the history update values ​​of the transform block with the existing history parameter values.

[0284]

[0275] Aspect 22: The method of any of aspects 20 or 21, wherein combining the historical update values ​​of the transformation block with the existing historical parameter values ​​comprises determining an exponentially weighted moving average between the historical update values ​​of the transformation block and the existing historical parameter values.

[0285]

[0276] Aspect 23: The method of aspect 22, further comprising assigning a first weight to a historical update value of the transformation block and a second weight to an existing historical parameter value, wherein determining the exponentially weighted moving average is based at least in part on the first weight and the second weight.

[0286]

[0277] Embodiment 24: The method of any of embodiments 20-23, wherein the history update value for the transform block is determined based on a first non-zero decoded transform coefficient determined in the analysis of the transform block.

[0287]

[0278] Embodiment 25: The method of embodiment 24, wherein the first non-zero decoded transform coefficient is determined based on a run scan order of the backward transform block.

[0288]

[0279] Aspect 26: The method of any of aspects 24 or 25, wherein the history update value of the transform block is determined at least in part by determining the binary code length of the first non-zero decoded transform coefficient.

[0289]

[0280] Aspect 27: A method of any of aspects 20 to 26, wherein the transform block and a previously analyzed transform block are associated with a first slice, and existing history parameter values ​​are iteratively updated based on successive history update values ​​determined for successively analyzed transform blocks associated with the same slice.

[0290]

[0281] Aspect 28: The method of aspect 27, further comprising initializing existing history parameter values ​​to predetermined values, wherein the initialization is performed before analyzing the first transform block of the first slice and determining the history update values ​​for the first transform block.

[0291]

[0282] Embodiment 29: The method of any of embodiments 20-28, wherein the history update value for the transform block is determined based on all of the non-zero decoded transform coefficients of the transform block.

[0292]

[0283] Embodiment 30: The method of embodiment 29, wherein the history update value is determined at least in part by averaging all of the non-zero decoded transform coefficients of the transform block.

[0293]

[0284] Aspect 31: The method of any one of aspects 20 to 30, wherein the existing history parameter value is an existing history Rice parameter value.

[0294]

[0285] Aspect 32: The method of any of aspects 20 to 31, wherein decoding at least one sample of the transform block comprises decoding a syntax element indicating the at least one sample based on existing history parameter values ​​or updated existing history parameter values.

[0295]

[0286] Aspect 33: The method of any of aspects 20 to 32, wherein decoding at least one sample of the transform block comprises decoding a Golomb-Rice code using existing history parameter values ​​or updated existing history parameter values.

[0296]

[0287] Aspect 34: An apparatus for decoding video data, comprising at least one memory and at least one processor coupled to the at least one memory, wherein the at least one processor is configured to: obtain a transform block; determine one or more parameters for a plurality of samples at least in part by analyzing a local neighborhood of a current sample among the plurality of samples, the transform block including a plurality of samples; determine, based at least in part on the analysis of the local neighborhood, that a number of neighboring transform coefficients of the current sample is less than a threshold amount; obtain historical parameter values ​​determined from one or more previously decoded transform blocks; determine parameters for the current sample based at least in part on the historical parameter values; and decode the current sample based on the determined parameters of the current sample.

[0297]

[0288] Aspect 35: The apparatus of aspect 34, wherein at least one processor is configured to determine parameters for the current sample based on a first integer multiple of the historical parameter value, based at least in part on a determination that the number of neighboring transform coefficients is 0.

[0298]

[0289] Aspect 36: The apparatus of aspect 35, wherein at least one processor is configured to provide a first integer multiple of the historical parameter value as an input to a lookup table that maps between inputs and parameters to determine parameters for the current sample.

[0299]

[0290] Aspect 37: The apparatus of any of aspects 35 or 36, wherein the first integer multiple and the threshold amount are the same value.

[0300]

[0291] Aspect 38: The device of any of aspects 35 to 37, wherein at least one processor is configured to determine a parameter of the current sample based on a second integer multiple of the historical parameter value and the sum of the neighboring transform coefficients, based at least in part on a determination that the number of neighboring transform coefficients is greater than 0.

[0301]

[0292] Aspect 39: The apparatus of aspect 38, wherein, to determine the parameters of the current sample, at least one processor is configured to provide the sum of the neighboring transform coefficients and a second integer multiple of the summed historical parameter value as an input to a lookup table that maps between inputs and parameters.

[0302]

[0293] Embodiment 40: The apparatus of embodiment 39, wherein the second integer multiple is smaller than the first integer multiple.

[0303]

[0294] Aspect 41: The device of any of aspects 34 to 40, wherein at least one processor is configured to determine that the number of neighboring transform coefficients is less than a threshold amount based at least in part on identifying one or more unavailable neighboring transform coefficients for the current sample.

[0304]

[0295] Aspect 42: The apparatus of aspect 41, wherein at least one processor is configured to obtain a location of a current sample within a transform block, compare the location of the current sample to one or more of the width of the transform block and the height of the transform block, and identify one or more unavailable neighboring transform coefficients based at least in part on the comparison.

[0305]

[0296] Embodiment 43: The apparatus of embodiment 42, wherein the one or more unavailable neighboring transform coefficients are associated with locations outside the transform block.

[0306]

[0297] Aspect 44: The device of any of aspects 42 or 43, wherein, to determine that the number of neighboring transform coefficients is less than a threshold amount, at least one processor is configured to determine that a horizontal component of the current sample location is within a first distance of the width of the transform block, and to determine that a vertical component of the current sample location is within a second distance of the height of the transform block.

[0307]

[0298] Embodiment 45: The apparatus of any of embodiments 34 to 44, wherein the plurality of samples are associated with a transform block sample type, and the transform block sample type includes a luma sample or a chroma sample.

[0308]

[0299] Aspect 46: The apparatus of aspect 45, wherein the transform block sample type is the same as a sample type associated with one or more previously decoded transform blocks from which the history parameter value is determined.

[0309]

[0300] Aspect 47: The device of any of aspects 34 to 46, wherein at least one processor is configured to determine a history parameter value based at least in part on a first non-zero decoded transform coefficient obtained from each of one or more previously decoded transform blocks.

[0310]

[0301] Aspect 48: The apparatus of aspect 47, wherein at least one processor is configured to determine a binary code length of each first non-zero decoded transform coefficient obtained from each of one or more previously decoded transform blocks.

[0311]

[0302] Aspect 49: The apparatus of aspect 48, wherein at least one processor is configured to determine the history parameter value as an exponentially weighted moving average of binary code lengths determined for the first non-zero decoded transform coefficient of each of one or more previously decoded transform blocks.

[0312]

[0303] Embodiment 50: An apparatus of any of embodiments 34 to 49, wherein the one or more parameters for the plurality of samples include one or more Rice parameters, the historical parameter values ​​are historical Rice parameter values, and the parameters determined for the current sample are Rice parameters of the current sample.

[0313]

[0304] Aspect 50: The apparatus of any of aspects 34 to 50, wherein decoding the current sample based on the determined parameters of the current sample comprises decoding a syntax element indicating the current sample based on the determined parameters.

[0314]

[0305] Aspect 50: The apparatus of any of aspects 34 to 51, wherein decoding the current sample based on the determined parameters comprises decoding a Golomb-Rice code using the determined parameters.

[0315]

[0306] Aspect 51: An apparatus for decoding video data, comprising at least one memory and at least one processor coupled to the at least one memory, wherein the at least one processor is configured to: obtain a transform block; determine one or more non-zero decoded transform coefficients based at least in part on an analysis of the transform block; determine a history update value for the transform block based at least in part on the one or more non-zero decoded transform coefficients; update existing history parameter values ​​at least in part by combining the history update value for the transform block with existing history parameter values; and the existing history parameter values ​​are based at least in part on a series of non-zero decoded transform coefficients determined from a series of previously analyzed transform blocks.

[0316]

[0307] Aspect 52: The apparatus of aspect 51, wherein at least one processor is configured to average the history update values ​​of the transform block with the existing history parameter values ​​to combine the history update values ​​of the transform block with the existing history parameter values.

[0317]

[0308] Aspect 53: The apparatus of any of aspects 51 or 52, wherein to combine the historical update values ​​of the transformation block with existing historical parameter values, at least one processor is configured to determine an exponentially weighted moving average between the historical update values ​​of the transformation block and the existing historical parameter values.

[0318]

[0309] Aspect 54: The apparatus of aspect 53, wherein at least one processor is configured to assign a first weight to a historical update value of the transformation block and a second weight to an existing historical parameter value, and to determine an exponentially weighted moving average based at least in part on the first weight and the second weight.

[0319]

[0310] Aspect 55: The device of any of aspects 51 to 54, wherein at least one processor is configured to determine a history update value for the transform block based on a first non-zero decoded transform coefficient determined in an analysis of the transform block.

[0320]

[0311] Aspect 56: The apparatus of aspect 55, wherein the at least one processor is configured to determine the first non-zero decoded transform coefficient based on a run scan order of the backward transform block.

[0321]

[0312] Aspect 57: The device of any of aspects 55 or 56, wherein at least one processor is configured to determine a history update value for the transform block at least in part by determining the binary code length of the first non-zero decoded transform coefficient.

[0322]

[0313] Aspect 58: An apparatus of any of aspects 51 to 57, wherein the transform block and a previously analyzed transform block are associated with a first slice, and at least one processor is configured to iteratively update existing history parameter values ​​based on successive history update values ​​determined for successively analyzed transform blocks associated with the same slice.

[0323]

[0314] Aspect 59: The apparatus of aspect 58, wherein at least one processor is configured to initialize existing history parameter values ​​to predetermined values, wherein the initialization is performed before analyzing the first transform block of the first slice and determining the history update values ​​for the first transform block.

[0324]

[0315] Embodiment 60: The apparatus of any of embodiments 51 to 59, wherein at least one processor is configured to determine a history update value for the transform block based on all of the non-zero decoded transform coefficients of the transform block.

[0325]

[0316] Aspect 61: The apparatus of aspect 60, wherein the at least one processor is configured to determine the history update value at least in part by averaging all of the non-zero decoded transform coefficients of the transform block.

[0326]

[0317] Aspect 62: The apparatus of any one of aspects 51 to 61, wherein the existing history parameter value is an existing history Rice parameter value.

[0327]

[0318] Aspect 63: The device of any of aspects 51 to 62, wherein decoding at least one sample of the transform block comprises decoding a syntax element indicating the at least one sample based on existing history parameter values ​​or updated existing history parameter values.

[0328]

[0319] Aspect 64: The apparatus of any of aspects 51 to 63, wherein decoding at least one sample of the transform block comprises decoding a Golomb-Rice code using existing history parameter values ​​or updated existing history parameter values.

[0329]

[0320] Aspect 65: A non-transitory computer-readable storage medium storing instructions that, when executed by one or more processors, cause the one or more processors to perform any of the operations of aspects 1 to 64.

[0330]

[0321] Aspect 66: An apparatus comprising means for performing any of the operations of aspects 1 to 64.

[0331]

[0322] Aspect 67: A method for processing video data, the method comprising: obtaining a plurality of coefficients associated with a block of video data; determining a classification of spatial locations of coefficients among the plurality of coefficients based on an estimated accuracy of a template-based derivation technique for deriving Rice parameters of the coefficients; determining Rice parameters of the coefficients based on the classification; and generating a bitstream based on the determined parameters for a current sample.

[0332]

[0323] Aspect 68: The method of aspect 67, further comprising determining the Rice parameters using a template-based derivation technique based on the estimated accuracy being greater than an accuracy threshold.

[0333]

[0324] Aspect 69: The method of aspect 67, further comprising determining the Rice parameter using a history-based derivation technique based on the estimated accuracy being less than an accuracy threshold.

[0334]

[0325] Aspect 70: The method of aspect 67, further comprising determining the Rice parameter using a function based on the estimated accuracy being less than an accuracy threshold, the function being based on a template-based derivation technique and a history-based derivation technique.

[0335]

[0326] Aspect 71: The method of aspect 70, wherein the function comprises a weighted average.

[0336]

[0327] Aspect 72: The method of aspect 70, wherein the function is incorporated into a template-based derivation technique.

[0337]

[0328] Embodiment 73: The method of any one of embodiments 67 to 72, wherein the classification is determined based on runs of a reverse scan order.

[0338]

[0329] Example 74: The method of any one of examples 67 to 73, further comprising generating an encoded video bitstream including a plurality of coefficients.

[0339]

[0330] Embodiment 75: The method of any one of embodiments 67 to 73, further comprising obtaining a plurality of coefficients from an encoded video bitstream.

[0340]

[0331] Aspect 76: An apparatus comprising a memory configured to store video data and a processor, wherein the processor is configured to obtain a plurality of coefficients associated with a block of the video data, determine a classification of spatial locations of coefficients among the plurality of coefficients based on an estimated accuracy of a template-based derivation technique for deriving Rice parameters of the coefficients, determine Rice parameters of the coefficients based on the classification, and generate a bitstream based on the determined parameters of a current sample.

[0341]

[0332] Aspect 77: The apparatus of aspect 76, further comprising determining the Rice parameters using a template-based derivation technique based on the estimated accuracy being greater than an accuracy threshold.

[0342]

[0333] Aspect 78: The apparatus of aspect 76, further comprising determining the Rice parameter using a history-based derivation technique based on the estimated accuracy being less than an accuracy threshold.

[0343]

[0334] Aspect 79: The apparatus of aspect 76, further comprising determining the Rice parameters using a function based on the estimated accuracy being less than an accuracy threshold, the function being based on a template-based derivation technique and a history-based derivation technique.

[0344]

[0335] Aspect 80: The apparatus of aspect 79, wherein the function includes a weighted average.

[0345]

[0336] Aspect 81: The apparatus of aspect 79, wherein the function is incorporated into a template-based derivation technique.

[0346]

[0337] Embodiment 82: The apparatus of any one of embodiments 76 to 81, wherein the classification is determined based on runs of a reverse scan order.

[0347]

[0338] Aspect 83: The apparatus of any one of aspects 76 to 82, further comprising generating an encoded video bitstream including a plurality of coefficients.

[0348]

[0339] Aspect 84: The apparatus of any one of aspects 76 to 82, further comprising obtaining a plurality of coefficients from an encoded video bitstream.

[0349]

[0340] Aspect 85: The apparatus of aspect 68, wherein the apparatus includes an encoder.

[0350]

[0341] Aspect 86: The apparatus of aspect 68, wherein the apparatus includes a decoder.

[0351]

[0342] Aspect 87: The apparatus of any one of aspects 68 to 78, wherein the apparatus is a mobile device.

[0352]

[0343] Aspect 88: The device of any one of aspects 68 to 79, wherein the device is an extended reality device.

[0353]

[0344] Aspect 89: The device of any one of aspects 68 to 80, further comprising a display configured to display video data.

[0354]

[0345] Embodiment 90: The apparatus of any one of embodiments 68 to 81, further comprising a camera configured to capture one or more pictures.

[0355]

[0346] Aspect 91: A computer-readable medium storing instructions that, when executed by a processor, implement the method of any of aspects 67 to 90.

[0356]

[0347] Aspect 92: An apparatus comprising means for performing the operations of any one of aspects 67 to 90.

[0357]

[0348] Aspect 93: A method for encoding video data, the method comprising: obtaining a transform block; determining one or more parameters for a plurality of samples at least in part by analyzing a local neighborhood of a current sample among the plurality of samples, the transform block including a plurality of samples; determining, based at least in part on the analysis of the local neighborhood, that a number of neighboring transform coefficients of the current sample is less than a threshold amount; obtaining historical parameter values ​​determined from one or more previously coded transform blocks; determining parameters for the current sample based at least in part on the historical parameter values; and generating a bitstream based on existing historical parameter values ​​or updated existing historical parameter values.

[0358]

[0349] Aspect 94: The method of aspect 93, further comprising determining a parameter of the current sample based on a first integer multiple of the historical parameter value, based at least in part on a determination that the number of neighboring transform coefficients is 0.

[0359]

[0350] Aspect 95: The method of aspect 94, wherein determining the parameter of the current sample comprises providing a first integer multiple of the historical parameter value as an input to a lookup table that maps between input and parameter, and the first integer multiple and the threshold amount are the same value.

[0360]

[0351] Aspect 96: The method of aspect 94, further comprising determining a parameter of the current sample based on a second integer multiple of the historical parameter value and the sum of the neighboring transform coefficients, based at least in part on a determination that the number of neighboring transform coefficients is greater than 0, wherein the second integer multiple is less than the first integer multiple.

[0361]

[0352] Aspect 97: The method of aspect 96, wherein determining the parameters of the current sample comprises providing the sum of the neighboring transform coefficients and a second integer multiple of the summed historical parameter value as an input to a lookup table that maps between inputs and parameters.

[0362]

[0353] Aspect 98: Any of the methods of aspects 93 to 97, wherein determining that the number of neighboring transform coefficients is less than a threshold amount is based at least in part on identifying one or more unavailable neighboring transform coefficients for the current sample, and the one or more unavailable neighboring transform coefficients are associated with locations outside the transform block.

[0363]

[0354] Aspect 99: The method of aspect 98, further comprising obtaining a location of a current sample within a transform block, comparing the location of the current sample to one or more of the width of the transform block and the height of the transform block, and identifying one or more unavailable neighboring transform coefficients based at least in part on the comparison.

[0364]

[0355] Aspect 100: The method of aspect 99, wherein determining that the number of neighboring transform coefficients is less than a threshold amount comprises determining that a horizontal component of the current sample location is within a first distance of the width of the transform block, and determining that a vertical component of the current sample location is within a second distance of the height of the transform block.

[0365]

[0356] Aspect 101: Any of the methods of aspects 93 to 100, wherein a plurality of samples are associated with a transform block sample type, the transform block sample type including luma samples or chroma samples, and the transform block sample type is the same as the sample type associated with one or more previously decoded transform blocks from which the history parameter values ​​are determined.

[0366]

[0357] Aspect 102: A method of any of aspects 93 to 101, wherein the history parameter value is determined based at least in part on the first non-zero decoded transform coefficient obtained from each of one or more previously coded transform blocks.

[0367]

[0358] Aspect 103: The method of aspect 102, further comprising determining a binary code length of each first non-zero decoded transform coefficient obtained from each of one or more previously coded transform blocks, wherein the history parameter value is determined as an exponentially weighted moving average of the binary code lengths determined for the first non-zero coded transform coefficient of each of the one or more previously coded transform blocks.

[0368]

[0359] Embodiment 104: A method of any of embodiments 93 to 103, wherein the one or more parameters for the plurality of samples include one or more Rice parameters, the historical parameter values ​​are historical Rice parameter values, and the parameters determined for the current sample are Rice parameters of the current sample.

[0369]

[0360] Aspect 105: An apparatus for encoding video data, comprising at least one memory and at least one processor coupled to the at least one memory, wherein the at least one processor is configured to: obtain a transform block; determine one or more non-zero coded transform coefficients based at least in part on an analysis of the transform block; determine history update values ​​for the transform block based at least in part on the one or more non-zero coded transform coefficients; update the existing history parameter values ​​at least in part by averaging the history update values ​​for the transform block with existing history parameter values; and generate a bitstream based on the existing history parameter values ​​or updated existing history parameter values, the existing history parameter values ​​being based at least in part on a series of non-zero coded transform coefficients determined from a series of previously analyzed transform blocks.

[0370]

[0361] Aspect 106: The apparatus of aspect 105, wherein, to update the existing history parameter values, at least one processor is configured to determine an exponentially weighted moving average between the history update values ​​of the transformation block and the existing history parameter values.

[0371]

[0362] Aspect 107: The apparatus of aspect 106, wherein at least one processor is configured to assign a first weight to a historical update value of the transformation block and a second weight to an existing historical parameter value, and to determine an exponentially weighted moving average based at least in part on the first weight and the second weight.

[0372]

[0363] Aspect 108: The device of any of aspects 105 to 107, wherein at least one processor is configured to determine a history update value for the transform block based on a first non-zero coded transform coefficient determined in an analysis of the transform block.

[0373]

[0364] Aspect 109: The apparatus of aspect 108, wherein the at least one processor is configured to determine the first non-zero coded transform coefficient based on a run scan order of the backward transform block.

[0374]

[0365] Aspect 110: The apparatus of aspect 108, wherein at least one processor is configured to determine a history update value of the transform block at least in part by determining a binary code length of the first non-zero coded transform coefficient.

[0375]

[0366] Aspect 111: An apparatus of any of aspects 105 to 110, wherein the transform block and a previously analyzed transform block are associated with a first slice, and at least one processor is configured to iteratively update existing history parameter values ​​based on successive history update values ​​determined for successively analyzed transform blocks associated with the same slice.

[0376]

[0367] Aspect 112: The apparatus of aspect 111, wherein at least one processor is configured to initialize existing history parameter values ​​to predetermined values, wherein the initialization is performed before analyzing the first transform block of the first slice and determining the history update values ​​for the first transform block.

[0377]

[0368] Embodiment 113: The device of any of embodiments 105 to 112, wherein at least one processor is configured to determine a history update value for the transform block based on all of the non-zero coded transform coefficients of the transform block.

[0378]

[0369] Aspect 114: The apparatus of aspect 113, wherein at least one processor is configured to determine the history update value at least in part by averaging all of the non-zero coded transform coefficients of the transform block.

[0379]

[0370] Embodiment 115: The apparatus of any one of embodiments 105 to 114, wherein the existing history parameter value is an existing history Rice parameter value.

[0380]

[0371] Aspect 116: A non-transitory computer-readable storage medium storing instructions that, when executed by one or more processors, cause the one or more processors to perform any of the operations of aspects 93 to 115.

[0381]

[0372] Aspect 117: An apparatus comprising means for performing any of the operations of aspects 93 to 115. The inventions described in the claims of the present application as originally filed are set forth below. [C1] 1. A method for decoding video data, comprising: obtaining a transform block, the transform block comprising a plurality of samples; determining one or more parameters for the plurality of samples at least in part by analyzing a local neighborhood of a current sample of the plurality of samples; determining, based at least in part on the analysis of the local neighborhood, that a number of neighboring transform coefficients of the current sample is less than a threshold amount; obtaining historical parameter values ​​determined from one or more previously decoded transform blocks; determining a parameter of the current sample based at least in part on the historical parameter value; decoding the current sample based on the determined parameters of the current sample; A method comprising: [C2] determining the parameter for the current sample based on a first integer multiple of the historical parameter value, based at least in part on determining that the number of neighboring transform coefficients is zero; The method of C1, further comprising: [C3] The method of C2, wherein determining the parameter of the current sample comprises providing the first integer multiple of the historical parameter value as an input to a lookup table that maps between inputs and parameters. [C4] The method of C2, wherein the first integer multiple and the threshold amount are the same value. [C5] determining the parameter for the current sample based on a second integer multiple of the historical parameter value and a sum of the neighboring transform coefficients, based at least in part on determining that the number of neighboring transform coefficients is greater than zero; The method of C2, further comprising: [C6] The method of C5, wherein determining the parameter for the current sample comprises providing the second integer multiple of the historical parameter value summed with the sum of the neighboring transform coefficients as an input to a lookup table that maps between input and parameter. [C7] The method of C6, wherein the second integer multiple is smaller than the first integer multiple. [C8] The method of C1, wherein determining that the number of neighboring transform coefficients is less than the threshold amount is based at least in part on identifying one or more unavailable neighboring transform coefficients for the current sample. [C9] obtaining a location of the current sample within the transform block; comparing the location of the current sample to one or more of a width of the transform block and a height of the transform block; identifying the one or more unavailable neighboring transform coefficients based at least in part on the comparison; and The method of C8, further comprising: [C10] The method of C9, wherein the one or more unavailable neighboring transform coefficients are associated with locations outside the transform block. [C11] Determining that the number of neighboring transform coefficients is less than the threshold amount includes: determining that a horizontal component of the location of the current sample is within a first distance of the width of the transform block; determining that a vertical component of the location of the current sample is within a second distance of the height of the transform block; The method of C9, comprising: [C12] The method of C1, wherein the plurality of samples are associated with a transform block sample type, the transform block sample type including a luma sample or a chroma sample. [C13] The method of C12, wherein the transform block sample type is the same as a sample type associated with the one or more previously decoded transform blocks from which the history parameter value is determined. [C14] The method of C1, wherein the history parameter value is determined based at least in part on a first non-zero decoded transform coefficient obtained from each of the one or more previously decoded transform blocks. [C15] The method of C14, further comprising determining a binary code length of each first non-zero decoded transform coefficient obtained from each of the one or more previously decoded transform blocks. [C16] The method of C15, wherein the history parameter value is determined as an exponentially weighted moving average of the binary code length determined for the first non-zero decoded transform coefficient of each of the one or more previously decoded transform blocks. [C17] The method of claim 1, wherein the one or more parameters for the plurality of samples include one or more Rice parameters, the historical parameter values ​​are historical Rice parameter values, and the parameters determined for the current sample are Rice parameters of the current sample. [C18] The method of C1, wherein decoding the current sample based on the determined parameters of the current sample comprises decoding a syntax element indicating the current sample based on the determined parameters. [C19] 3. The method of claim 1, wherein decoding the current sample based on the determined parameters comprises decoding a Golomb-Rice code using the determined parameters. [C20] 1. A method for decoding video data, comprising: Obtaining a transformation block; determining one or more non-zero decoded transform coefficients based at least in part on an analysis of the transform block; and determining a history update value for the transform block based at least in part on the one or more non-zero decoded transform coefficients; updating the existing history parameter values ​​at least in part by combining the history update values ​​for the transform block with existing history parameter values, the existing history parameter values ​​being based at least in part on a set of non-zero decoded transform coefficients determined from a set of previously analyzed transform blocks; decoding at least one sample of the transform block based on the existing historical parameter values ​​or the updated existing historical parameter values; A method comprising: [C21] The method of C20, wherein combining the history update values ​​of the transform block with the existing history parameter values ​​comprises averaging the history update values ​​of the transform block with the existing history parameter values. [C22] The method of C20, wherein combining the history update values ​​of the transformation block with the existing history parameter values ​​comprises determining an exponentially weighted moving average between the history update values ​​of the transformation block and the existing history parameter values. [C23] further comprising assigning a first weight to the history update value of the transformation block and a second weight to the existing history parameter value; The method of C22, wherein determining the exponentially weighted moving average is based at least in part on the first weight and the second weight. [C24] The method of C20, wherein the history update value for the transform block is determined based on a first non-zero decoded transform coefficient determined in the analysis of the transform block. [C25] The method of C24, wherein the first non-zero decoded transform coefficient is determined based on a run scan order of the transform block in a backward direction. [C26] The method of C24, wherein the history update value for the transform block is determined at least in part by determining a binary code length of the first non-zero decoded transform coefficient. [C27] the transform block and the previously analyzed transform block are associated with a first slice; the existing history parameter values ​​are iteratively updated based on successive history update values ​​determined for successively analyzed transform blocks associated with the same slice. The method described in C20. [C28] further comprising initializing the existing historical parameter values ​​to predetermined values; the initializing is performed before analyzing a first transform block of the first slice and determining a history update value for the first transform block. The method described in C27. [C29] The method of C20, wherein the history update value for the transform block is determined based on all of the non-zero decoded transform coefficients of the transform block. [C30] The method of C29, wherein the history update value is determined at least in part by averaging all of the non-zero decoded transform coefficients of the transform block. [C31] The method of C20, wherein the existing historical parameter values ​​are existing historical Rice parameter values. [C32] The method of C20, wherein decoding the at least one sample of the transform block comprises decoding a syntax element indicating the at least one sample based on the existing history parameter value or the updated existing history parameter value. [C33] The method of C20, wherein decoding the at least one sample of the transform block comprises decoding a Golomb-Rice code using the existing history parameter values ​​or the updated existing history parameter values. [C34] 1. An apparatus for decoding video data, comprising: At least one memory; at least one processor coupled to the at least one memory, the at least one processor comprising: obtaining a transform block, the transform block comprising a plurality of samples; determining one or more parameters for the plurality of samples at least in part by analyzing a local neighborhood of a current sample of the plurality of samples; determining, based at least in part on the analysis of the local neighborhood, that a number of neighboring transform coefficients of the current sample is less than a threshold amount; obtaining historical parameter values ​​determined from one or more previously decoded transform blocks; determining a parameter of the current sample based at least in part on the historical parameter value; decoding the current sample based on the determined parameters of the current sample; An apparatus configured to: [C35] The at least one processor: The apparatus of C34, configured to determine the parameter for the current sample based on a first integer multiple of the historical parameter value, based at least in part on a determination that the number of neighboring transform coefficients is zero. [C36] To determine the parameters of the current sample, the at least one processor: The apparatus of C35, configured to provide the first integer multiple of the historical parameter value as an input to a lookup table that maps between inputs and parameters. [C37] The apparatus of C35, wherein the first integer multiple and the threshold amount are the same value. [C38] The at least one processor: The apparatus of C35, configured to determine the parameter of the current sample based on a second integer multiple of the historical parameter value and a sum of the neighboring transform coefficients, based at least in part on a determination that the number of neighboring transform coefficients is greater than 0. [C39] To determine the parameters of the current sample, the at least one processor: The apparatus of C38, configured to provide the second integer multiple of the historical parameter value summed with the sum of the neighboring transform coefficients as an input to a lookup table that maps between inputs and parameters. [C40] The apparatus of C39, wherein the second integer multiple is smaller than the first integer multiple. [C41] The apparatus of C34, wherein the at least one processor is configured to determine that the number of neighboring transform coefficients is less than the threshold amount based at least in part on identifying one or more unavailable neighboring transform coefficients for the current sample. [C42] The at least one processor: obtaining a location of the current sample within the transform block; comparing the location of the current sample to one or more of a width of the transform block and a height of the transform block; identifying the one or more unavailable neighboring transform coefficients based at least in part on the comparison; and The apparatus of C41, configured to perform the following. [C43] The apparatus of C42, wherein the one or more unavailable neighboring transform coefficients are associated with locations outside the transform block. [C44] To determine that the number of neighboring transform coefficients is less than the threshold amount, the at least one processor: determining that a horizontal component of the location of the current sample is within a first distance of the width of the transform block; determining that a vertical component of the location of the current sample is within a second distance of the height of the transform block; The apparatus of C42, configured to perform the following: [C45] The apparatus of C44, wherein the plurality of samples are associated with a transform block sample type, the transform block sample type including a luma sample or a chroma sample. [C46] The apparatus of C45, wherein the transform block sample type is the same as a sample type associated with the one or more previously decoded transform blocks from which the history parameter value is determined. [C47] The at least one processor: The apparatus of C44, configured to determine the history parameter value based at least in part on a first non-zero decoded transform coefficient obtained from each of the one or more previously decoded transform blocks. [C48] The at least one processor: The apparatus of C47, configured to determine a binary code length of each first non-zero decoded transform coefficient obtained from each of the one or more previously decoded transform blocks. [C49] The at least one processor: The apparatus of C48, configured to determine the history parameter value as an exponentially weighted moving average of the binary code length determined for the first non-zero decoded transform coefficient of each of the one or more previously decoded transform blocks. [C50] The apparatus of C34, wherein the one or more parameters for the plurality of samples include one or more Rice parameters, the historical parameter values ​​are historical Rice parameter values, and the parameters determined for the current sample are Rice parameters of the current sample. [C51] To decode the current sample based on the determined parameters of the current sample, the at least one processor: The apparatus of C34, configured to decode a syntax element indicating the current sample based on the determined parameters. [C52] To decode the current sample based on the determined parameters of the current sample, the at least one processor: 34. The apparatus of claim 33, configured to decode a Golomb-Rice code using the determined parameters. [C53] 1. An apparatus for decoding video data, comprising: At least one memory; at least one processor coupled to the at least one memory, the at least one processor comprising: Obtaining a transformation block; determining one or more non-zero decoded transform coefficients based at least in part on an analysis of the transform block; and determining a history update value for the transform block based at least in part on the one or more non-zero decoded transform coefficients; updating the existing history parameter values ​​at least in part by combining the history update values ​​for the transform block with existing history parameter values, the existing history parameter values ​​being based at least in part on a set of non-zero decoded transform coefficients determined from a set of previously analyzed transform blocks; decoding at least one sample of the transform block based on the existing historical parameter values ​​or the updated existing historical parameter values; An apparatus configured to: [C54] To combine the history update values ​​of the transformation block with the existing history parameter values, the at least one processor: The apparatus of C53, configured to average the history update value of the transformation block with the existing history parameter value. [C55] To combine the history update values ​​of the transformation block with the existing history parameter values, the at least one processor: The apparatus of C53, configured to determine an exponentially weighted moving average between the historical update values ​​and the existing historical parameter values ​​of the transformation block. [C56] The at least one processor: assigning a first weight to the history update value and a second weight to the existing history parameter value of the transformation block; determining the exponentially weighted moving average based at least in part on the first weight and the second weight; The apparatus of C55, configured to perform the following: [C57] The apparatus of C56, wherein the at least one processor is configured to determine the history update value for the transform block based on a first non-zero decoded transform coefficient determined in the analysis of the transform block. [C58] The apparatus of C57, wherein the at least one processor is configured to determine the first non-zero decoded transform coefficient based on a run scan order of the transform block in a backward direction. [C59] The apparatus of C57, wherein the at least one processor is configured to determine the history update value for the transform block at least in part by determining a binary code length of the first non-zero decoded transform coefficient. [C60] the transform block and the previously analyzed transform block are associated with a first slice; the at least one processor is configured to iteratively update the existing history parameter values ​​based on successive history update values ​​determined for successively analyzed transform blocks associated with the same slice. The device described in C56. [C61] the at least one processor is configured to initialize the existing historical parameter values ​​to predetermined values; The apparatus of C60, wherein the initializing is performed before analyzing a first transform block of the first slice and determining a history update value for the first transform block. [C62] The apparatus of C56, wherein the at least one processor is configured to determine the history update value for the transform block based on all of the non-zero decoded transform coefficients of the transform block. [C63] The apparatus of C62, wherein the at least one processor is configured to determine the history update value at least in part by averaging all of the non-zero decoded transform coefficients of the transform block. [C64] The apparatus of C56, wherein the existing historical parameter values ​​are existing historical Rice parameter values. [C65] To decode the at least one sample of the transform block, the at least one processor: The apparatus of C53, configured to decode a syntax element indicating the at least one sample based on the existing history parameter value or the updated existing history parameter value. [C66] To decode the at least one sample of the transform block, the at least one processor: The apparatus of C53, configured to decode a Golomb-Rice code using the existing history parameter values ​​or the updated existing history parameter values.

Claims

1. 1. A method for decoding video data, comprising: obtaining a transform block, the transform block comprising a plurality of samples; determining one or more Rice parameters for the plurality of samples at least in part by analyzing a local neighborhood of a current sample of the plurality of samples; determining, based on the analysis of the local neighborhood, that a number of neighboring transform coefficients of the current sample is less than a threshold amount, wherein the determining includes identifying one or more unavailable neighboring transform coefficients for the current sample; obtaining, for each unavailable neighboring transform coefficient of the one or more unavailable neighboring transform coefficients, a history parameter value determined from transform coefficients of one or more previously decoded transform blocks; determining a Rice parameter for the current sample based on using the historical parameter value for each unavailable neighboring transform coefficient of the one or more unavailable neighboring transform coefficients; decoding the current sample based on the determined Rice parameter of the current sample; A method comprising:

2. determining the Rice parameter for the current sample based on a first integer multiple of the historical parameter value based on a determination that the number of neighboring transform coefficients is zero; The method of claim 1 further comprising:

3. 3. The method of claim 2, wherein determining the Rice parameter for the current sample comprises providing the first integer multiple of the historical parameter value as an input to a lookup table that maps between inputs and Rice parameters.

4. The method of claim 2 , wherein the first integer multiple and the threshold amount are the same value.

5. determining the Rice parameter for the current sample based on a second integer multiple of the historical parameter value and a sum of the neighboring transform coefficients, based at least in part on a determination that the number of neighboring transform coefficients is greater than zero; and optionally further comprising: determining the Rice parameter for the current sample comprises providing the second integer multiple of the historical parameter value summed with the sum of the neighboring transform coefficients as an input to a lookup table that maps between inputs and Rice parameters; and optionally The method of claim 2 , wherein the second integer multiple is less than the first integer multiple.

6. obtaining a location of the current sample within the transform block; comparing the location of the current sample to one or more of a width of the transform block and a height of the transform block; identifying the one or more unavailable neighboring transform coefficients based at least in part on the comparison; and The method of claim 1 further comprising:

7. The method of claim 6 , wherein the one or more unavailable neighboring transform coefficients are associated with locations outside the transform block.

8. Determining that the number of neighboring transform coefficients is less than the threshold amount includes: determining that a horizontal component of the location of the current sample is within a first distance of the width of the transform block; determining that a vertical component of the location of the current sample is within a second distance of the height of the transform block; The method of claim 6 , comprising:

9. the plurality of samples are associated with a transform block sample type, the transform block sample type comprising luma samples or chroma samples; and optionally The method of claim 1 , wherein the transform block sample type is the same as a sample type associated with the one or more previously decoded transform blocks from which the history parameter values ​​are determined.

10. the history parameter value is determined based at least in part on a first non-zero decoded transform coefficient obtained from each of the one or more previously decoded transform blocks; and optionally determining a binary code length of each first non-zero decoded transform coefficient obtained from each of the one or more previously decoded transform blocks; and optionally 2. The method of claim 1, wherein the history parameter value is determined as an exponentially weighted moving average of the binary code lengths determined for the first non-zero decoded transform coefficient of each of the one or more previously decoded transform blocks.

11. 2. The method of claim 1 , wherein decoding the current sample based on the determined Rice parameter for the current sample comprises decoding a syntax element indicating the current sample based on the determined Rice parameter or a Golomb-Rice code using the determined Rice parameter.

12. 1. An apparatus for decoding video data, comprising: at least one memory; at least one processor coupled to the at least one memory, the at least one processor comprising: obtaining a transform block, the transform block comprising a plurality of samples; determining one or more Rice parameters for the plurality of samples at least in part by analyzing a local neighborhood of a current sample of the plurality of samples; determining, based on the analysis of the local neighborhood identifying one or more unavailable neighboring transform coefficients for the current sample, that a number of neighboring transform coefficients of the current sample is less than a threshold amount; obtaining, for each unavailable neighboring transform coefficient of the one or more unavailable neighboring transform coefficients, a history parameter value determined from transform coefficients of one or more previously decoded transform blocks; determining a Rice parameter for the current sample based on using the historical parameter value for each unavailable neighboring transform coefficient of the one or more unavailable neighboring transform coefficients; decoding the current sample based on the determined Rice parameter of the current sample; An apparatus configured to:

13. The apparatus of claim 12, wherein the at least one processor is further configured to perform the method of any one of claims 1 to 11.

14. A non-transitory computer-readable storage medium storing instructions that, when executed by one or more processors, cause the one or more processors to perform the method of any one of claims 1 to 11.

Images