To derive the RICE parameters for coding high-bit-depth video data.

Abstract

An exemplary device for coding video data includes a memory configured to store the video data and one or more processors implemented in a circuit, where the one or more processors are configured to: calculate a sum of absolute values ​​of a plurality of adjacent coefficients relative to a current coefficient for a current block of the video data; calculate a base level offset value according to a bit depth for the video data and a slice type for a slice that includes the current block; calculate a normalized value for the sum of absolute values ​​using the base level offset value; and code the current coefficient using the normalized value for the sum of absolute values.

Description

Claim of Priority

[0001]

[0001] This application claims the priority of U.S. Patent Application No. 17 / 658,396, filed on April 7, 2022, and U.S. Provisional Application No. 63 / 173,269, filed on April 9, 2021, the entire contents of each of which are incorporated herein by reference. U.S. Patent Application No. 17 / 658,396, filed on April 7, 2022, claims the benefit of U.S. Provisional Application No. 63 / 173,269, filed on April 9, 2021.

Technical Field

[0002]

[0002] The present disclosure relates to video coding, including video encoding and video decoding.

Background Art

[0003]

[0003] Digital video capabilities can be incorporated into a wide range of devices, including digital televisions, digital direct broadcast systems, wireless broadcast systems, personal digital assistants (PDAs), laptop or desktop computers, tablet computers, e-book readers, digital cameras, digital recording devices, digital media players, video gaming devices, video game consoles, cellular or satellite radio phones, so-called "smartphones," video teleconferencing devices, video streaming devices, and the like. Digital video devices implement video coding techniques, such as those described in standards defined by MPEG-2, MPEG-4, ITU-T H.263, ITU-T H.264 / MPEG-4, Part 10, Advanced Video Coding (AVC), ITU-T H.265 / High Efficiency Video Coding (HEVC), ITU-T H.266 / General Purpose Video Coding (VVC), and extensions of such standards, as well as video coding techniques described in proprietary video codecs / formats such as AOMedia Video1 (AV1) developed by the Alliance for Open Media. Video devices can transmit, receive, encode, decode, and / or store digital video information more efficiently by implementing such video coding techniques.

[0004]

[0004] Video coding techniques include spatial (intra-picture) prediction and / or temporal (inter-picture) prediction to reduce or eliminate redundancy inherent in video sequences. In block-based video coding, a video slice (e.g., a video picture or a portion of a video picture) may be divided into video blocks, which may also be called coding tree units (CTUs), coding units (CUs), and / or coding nodes. A video block in an intra-coded (I) slice of a picture is coded using spatial prediction for a reference sample in an adjacent block within the same picture. A video block in an inter-coded (P or B) slice of a picture may use spatial prediction for a reference sample in an adjacent block within the same picture, or temporal prediction for a reference sample in another reference picture. A picture may be called a frame, and a reference picture may be called a reference frame. [Overview of the Initiative]

[0005]

[0005] Generally speaking, this disclosure describes techniques for deriving Rice parameters for coding video data, for example, high-bit-depth video data. In particular, Rice parameters may be used when performing regular residual coding (RRC), which may include encoding and / or decoding. These techniques may be applied in ITU-T H.266 / General-Purpose Video Coding (VVC) or other video coding standards. The techniques of this disclosure generally concern the determination of Rice parameters to be used to binarize the current coefficients of a transformation block of video data, wherein the determination of Rice parameters includes using a base-level offset value. The base-level offset value may be calculated according to at least one of the bit depth for the video data or the slice type for the slice of video data. The base-level offset value may then be applied to the sum of the absolute values ​​of the coefficients adjacent to the current coefficient in order to calculate a normalized value. The normalized value may be used to determine the Rice parameter, for example, from a lookup table. The Rice parameter may then be used to binarize the values ​​for the current coefficient.

[0006]

[0006] In one example, a method for coding (encoding and / or decoding) video data includes: calculating the sum of the absolute values ​​of several adjacent coefficients for the current coefficient for the current block of video data; calculating a base-level offset value according to at least one of the bit depth for the video data or the slice type for the slice containing the current block; calculating a normalized value for the sum of absolute values ​​using the base-level offset value; and coding the current coefficient using the normalized value for the sum of absolute values.

[0007]

[0007] In another example, a device for coding (encoding and / or decoding) video data includes a memory configured to store the video data and one or more processors implemented in the circuit, the one or more processors configured to calculate the sum of the absolute values ​​of a number of adjacent coefficients for the current coefficient for the current block of video data, calculate a base-level offset value according to at least one of the bit depth for the video data or the slice type for the slice containing the current block, calculate a normalized value for the sum of absolute values ​​using the base-level offset value, and code the current coefficient using the normalized value for the sum of absolute values.

[0008]

[0008] In another example, a computer-readable storage medium stores instructions that, when executed, cause a processor in a device for coding video data to calculate the sum of the absolute values ​​of several adjacent coefficients for the current coefficient for the current block of video data; calculate a base-level offset value according to at least one of the bit depth for the video data or the slice type for the slice containing the current block; calculate a normalized value for the sum of absolute values ​​using the base-level offset value; and code the current coefficient using the normalized value for the sum of absolute values.

[0009]

[0009] In another example, a device for coding (encoding and / or decoding) video data includes means for calculating the sum of the absolute values ​​of a plurality of adjacent coefficients with respect to the current coefficient for the current block of video data; means for calculating a base-level offset value according to at least one of the bit depth for the video data or the slice type for the slice containing the current block; means for calculating a normalized value for the sum of absolute values ​​using the base-level offset value; and means for coding the current coefficient using the normalized value for the sum of absolute values.

[0010]

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

[0011] [Figure 1]

[0011] A block diagram showing an exemplary video coding and decoding system capable of implementing the techniques of the present disclosure. [Figure 2]

[0012] A conceptual diagram showing an example of adjacent coefficients to current coefficients that can be used to calculate the sum of local absolute values ​​(locSumAbs). [Figure 3]

[0013] A graph showing an empirical histogram of coded conversion coefficients for a 16-bit test sequence of video data. [Figure 4]

[0014] A graph showing the relationship between the codeword length generated during entropy coding for coefficient values ​​and a given Rice parameter. [Figure 5]

[0015] A block diagram showing an exemplary video encoder capable of implementing the techniques of this disclosure. [Figure 6]

[0016] A block diagram illustrating an exemplary video decoder capable of implementing the techniques of this disclosure. [Figure 7]

[0017] A flowchart illustrating an exemplary method for encoding a current block using the technique of the present disclosure. [Figure 8]

[0018] A flowchart illustrating an exemplary method for decoding a current block using the technique of the present disclosure. [Figure 9]

[0019] A flowchart illustrating an exemplary method for encoding video data using the techniques of this disclosure. [Figure 10]

[0020] A flowchart illustrating an exemplary method for decoding video data using the techniques of this disclosure. [Modes for carrying out the invention]

[0012]

[0021] Rice parameter values ​​can be used to code (encode or decode) the coefficients of residual blocks in video data. In particular, rice parameters can be used when binarizing values ​​in relation to entropy coding (encode or decode) the values. The use of rice parameter values ​​ranging from 0 to 3, including both extreme values, was extensively tested in the development of the ITU-T H.266 / General-Purpose Video Coding (VVC) standard. Generally, rice parameter values ​​are scaled using a clipping formula that also takes the bit depth of the corresponding video data as input. The clipping formulas initially developed for VVC assumed a bit depth of 8 or 10 bits. However, when the bit depth increases beyond 10 bits, the clipping function may no longer effectively clip the rice parameter values ​​to within the 0-3 bit range, which can lead to a rapid increase in codeword size and, therefore, the signaled values ​​in the bitstream. This disclosure describes techniques for avoiding the increase in codeword size and the data signaled in the bitstream when using Rice parameters to code video data using high bit depth (e.g., bit depth beyond 10 bits).

[0013]

[0022] A video coder (encoder or decoder) may be configured to use the technique of the present disclosure to code (encode or decode) values ​​for the current coefficients of a transformation block. In particular, the video coder may first calculate the sum of the absolute values ​​of adjacent coefficients for the current coefficient. The video coder may then calculate a base-level offset value to be applied to the sum of absolute values ​​according to either or both the bit depth for the video data and / or the slice type for the slice containing the transformation block. The video coder may then calculate a normalized value for the sum of absolute values ​​using the base-level offset value. The video coder may then code the current coefficient using the normalized value. As described above, the technique of the present disclosure may be applied in a context in which the bit depth can be extended beyond 10 bits. Thus, calculating the base-level offset value according to the bit depth may allow the Rice parameter to be clipped so that it remains within 0 to 3 bits.

[0014]

[0023] Video coding standards 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, and ITU-T H.264 (also known as ISO / IEC MPEG-4 AVC), which includes its Scalable Video Coding (SVC) and Multiview Video Coding (MVC) extensions. High Efficiency Video Coding (HEVC) was established in April 2013 by the Joint Collaboration Team on Video Coding (JCT-VC) between the ITU-T Video Coding Expert Group (VCEG) and the ISO / IEC Motion Picture Expert Group (MPEG).

[0015]

[0024] The Joint Video Expert Team (JVET), a collaborative team formed by MPEG and VCEG of ITU-T Study Group 16, continues to develop video coding techniques for and beyond the Versatile Video Coding (VVC) standard. The main objective of VVC is to provide a significant improvement in compression performance beyond the existing HEVC standard to facilitate the deployment of higher-quality video services and emerging applications such as 360° omnidirectional immersive multimedia and high dynamic range (HDR) video. The draft of the VVC standard can be found in Benjamin Bross, Jianle Chen, Shan Liu, and Ye-Kui Wang, "Versatile Video Coding (Draft 10)", Doc. JVET-S2001, Joint Video Expert Team (JVET) of ITU-T SG16 WP3 and ISO / IEC JTC1 / SC29 / WG11, 19th Meeting: Teleconference, June 22 - July 1, 2020, available at phenix.it-sudparis.eu / jvet / doc_end_user / documents / 19_Teleconference / wg11 / JVET-S2001-v17.zip.

[0016]

[0025] FIG. 1 is a block diagram illustrating an exemplary video encoding and decoding system 100 in which the techniques of the present disclosure may be implemented. The techniques of the present disclosure generally are directed to coding (encoding and / or decoding) video data. Generally, video data includes any data for processing video. Thus, video data may include raw uncoded video, encoded video, decoded (e.g., reconstructed) video, and video metadata such as signaling data.

[0017]

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

[0018]

[0027] In the example in Figure 1, the source device 102 includes a video source 104, a memory 106, a video encoder 200, and an output interface 108. The destination device 116 includes an input interface 122, a video decoder 300, a memory 120, and a display device 118. According to this disclosure, the video encoder 200 of the source device 102 and the video decoder 300 of the destination device 116 may be configured to apply a technique for coding high-bit-depth video data using RICE parameters. Thus, the source device 102 represents an example of a video encoding device, and the destination device 116 represents an example of a video decoding device. In other examples, the source and destination devices may include other components or arrangements. For example, the source device 102 may receive video data from an external video source, such as an external camera. Similarly, the destination device 116 may interface with an external display device rather than including an integrated display device.

[0019]

[0028] The system 100 shown in FIG. 1 is merely an example. Generally, any digital video encoding and / or decoding device may implement techniques for coding high bit-depth video data using Rice parameters. The source device 102 and the destination device 116 are merely examples of coding devices that generate video data coded for transmission from the source device 102 to the destination device 116. This disclosure refers to a “coding” device as a device that performs data coding (encoding and / or decoding). Thus, the video encoder 200 and the video decoder 300 represent examples of coding devices, particularly a video encoder and a video decoder, respectively. In some examples, the source device 102 and the destination device 116 may operate substantially symmetrically such that each of the source device 102 and the destination device 116 includes video encoding components and video decoding components. Thus, the system 100 may support one-way or two-way video transmission between the source device 102 and the destination device 116, for example, for video streaming, video playback, video broadcasting, or video telephony.

[0020]

[0029] Generally, the video source 104 represents a source of video data (i.e., raw, uncoded video data), providing the video encoder 200 with a sequence of pictures (also called "frames") of video data, which the video encoder 200 then encodes data about the pictures. The video source 104 of source device 102 may include video capture devices, such as a video camera, a video archive containing previously captured raw video, and / or a video feed interface for receiving video from a video content provider. As a further alternative, the video source 104 may generate computer graphics-based data as source video, or a combination of live video, archived video, and computer-generated video. In each case, the video encoder 200 encodes the captured video data, pre-captured video data, or computer-generated video data. The video encoder 200 may rearrange the pictures from the order they are received (sometimes called the "display order") to the coding order for encoding. The video encoder 200 may generate a bitstream containing the encoded video data. The source device 102 may then output the encoded video data onto a computer-readable medium 110 via the output interface 108 for reception and / or retrieval by the input interface 122 of the destination device 116, for example.

[0021]

[0030] Memory 106 of source device 102 and memory 120 of destination device 116 represent general-purpose memory. In some examples, memories 106 and 120 may store raw video data, for example, raw video from video source 104, and raw decoded video data from video decoder 300. Additional or alternative, memories 106 and 120 may store, for example, software instructions executable by video encoder 200 and video decoder 300, respectively. Although memories 106 and 120 are shown separately from video encoder 200 and video decoder 300 in this example, it should be understood that video encoder 200 and video decoder 300 may also include internal memory for functionally similar or equivalent purposes. Furthermore, memories 106 and 120 may store encoded video data, for example, output from video encoder 200 and input to video decoder 300. In some examples, portions 106 and 120 of memory may be allocated as one or more video buffers to store, for example, raw decoded and / or encoded video data.

[0022]

[0031] The computer-readable medium 110 may represent any type of medium or device capable of transporting encoded video data from the source device 102 to the destination device 116. For example, the computer-readable medium 110 may represent a communication medium that enables the source device 102 to directly transmit encoded video data to the destination device 116 in real time, for example, over a radio frequency network or a computer-based network. The output interface 108 may modulate the transmission signal containing the encoded video data, and the input interface 122 may demodulate the received transmission signal according to a communication standard such as a wireless communication protocol. 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 to facilitate communication from the source device 102 to the destination device 116.

[0023]

[0032] In some examples, source device 102 may output encoded data to storage device 112 via output interface 108. Similarly, destination device 116 may access encoded data from storage device 112 via input interface 122. Storage device 112 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.

[0024]

[0033] In some examples, the source device 102 may output the encoded video data to a file server 114 or another intermediate storage device capable of storing the encoded video data generated by the source device 102. The destination device 116 may access the stored video data from the file server 114 via streaming or download.

[0025]

[0034] The file server 114 can be any type of server device capable of storing encoded video data and transmitting that encoded video data to the destination device 116. The file server 114 may represent a web server (for example, for a website), a server configured to provide a file transfer protocol service (such as the File Transfer Protocol (FTP) or File Delivery over Unidirectional Transport (FLUTE) protocol), a Content Delivery Network (CDN) device, a Hypertext Transfer Protocol (HTTP) server, a Multimedia Broadcast Multicast Service (MBMS) or Enhanced MBMS (eMBMS) server, and / or a Network Attached Storage (NAS) device. The file server 114 may, in addition or alternatively, implement one or more HTTP streaming protocols, such as Dynamic Adaptive Streaming over HTTP (DASH), HTTP Live Streaming (HLS), Real-Time Streaming Protocol (RTSP), or HTTP Dynamic Streaming.

[0026]

[0035] The destination device 116 may access the encoded video data from the file server 114 through any standard data connection, including an internet connection. This may include wireless channels (e.g., Wi-Fi® connection), wired connections (e.g., digital subscriber line (DSL), cable modem, etc.), or a combination of both, which are suitable for accessing the encoded video data stored in the file server 114. The input interface 122 may be configured to operate according to one or more of the various protocols described above for retrieving or receiving media data from the file server 114, or any other such protocols for retrieving media data.

[0027]

[0036] The output interface 108 and input interface 122 may represent a wireless transmitter / receiver, a modem, a wired networking component (e.g., an Ethernet® card), a wireless communication component operating according to any of the various IEEE 802.11 standards, or other physical components. In examples where the output interface 108 and input interface 122 include wireless components, the output interface 108 and input interface 122 may be configured to transfer data such as encoded video data according to cellular communication standards such as 4G, 4G-LTE® (Long-Term Evolution), LTE Advanced, or 5G. In some examples where the output interface 108 includes a wireless transmitter, the output interface 108 and input interface 122 may be configured to transfer data such as encoded video data according to other wireless standards such as the IEEE 802.11 specification, the IEEE 802.15 specification (e.g., ZigBee®), or the Bluetooth® standard. In some examples, the source device 102 and / or destination device 116 may include their respective system-on-chip (SoC) devices. For example, the source device 102 may include an SoC device for performing functions associated with the video encoder 200 and / or the output interface 108, and the destination device 116 may include an SoC device for performing functions associated with the video decoder 300 and / or the input interface 122.

[0028]

[0037] The techniques of this disclosure can be applied to video coding that supports any of a variety of multimedia applications, such as over-the-air television broadcasting, 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.

[0029]

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

[0030]

[0039] Although not shown in Figure 1, in some examples, the video encoder 200 and video decoder 300 may be integrated with an audio encoder and / or audio decoder, respectively, and may include a suitable MUX-DEMUX unit or other hardware and / or software to handle a multiplexed stream containing both audio and video in a common data stream.

[0031]

[0040] The video encoder 200 and video decoder 300 can each be implemented as one or more suitable encoder and / or decoder circuits, or any combination thereof, including one or more microprocessors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), discrete logic, software, hardware, firmware, etc. When the technique is partially implemented in software, the device may store instructions for the software in a suitable non-temporary computer-readable medium and execute those instructions in hardware using one or more processors to implement the technique of the Disclosure. Each of the video encoder 200 and video decoder 300 may be comprised of one or more encoders or decoders, any of which may be integrated as part of a composite encoder / decoder (codec) in their respective devices. A device including the video encoder 200 and / or video decoder 300 may comprise an integrated circuit, a microprocessor, and / or a wireless communication device such as a cellular telephone.

[0032]

[0041] The video encoder 200 and video decoder 300 may operate in accordance with video coding standards such as ITU-T H.265, also known as High Efficiency Video Coding (HEVC), or its extensions such as the Multiview and / or Scalable Video Coding Extension. Alternatively, the video encoder 200 and video decoder 300 may operate in accordance with other proprietary or industry standards such as ITU-T H.266, also known as General-Purpose Video Coding (VVC). In other examples, the video encoder 200 and video decoder 300 may operate in accordance with proprietary video codecs / formats such as AOMedia Video1 (AV1), extensions of AVI, and / or successor versions of AV1 (e.g., AV2). In other examples, the video encoder 200 and video decoder 300 may operate in accordance with other proprietary formats or industry standards. However, the techniques of this disclosure are not limited to any particular coding standard or format. In general, the video encoder 200 and video decoder 300 may be configured to implement the techniques of the present disclosure, along with any video coding technique that codes high-bit-depth video data using Rice parameters.

[0033]

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

[0034]

[0043] This disclosure may refer to coding a picture (e.g., encoding and decoding) to include, in general, the process of encoding or decoding the data of a picture. Similarly, this disclosure may refer to coding a block of a picture to include, for example, the process of encoding or decoding data about a block, for example, predictive and / or residual coding. An encoded video bitstream generally contains a set of values ​​for syntax elements that represent coding decisions (e.g., coding modes) and divisions of the picture into blocks. Thus, references to coding a picture or a block should generally be understood as coding values ​​for the syntax elements that make up the picture or block.

[0035]

[0044] HEVC defines various blocks, including coding units (CUs), prediction units (PUs), and transformation units (TUs). According to HEVC, a video coder (such as video encoder 200) divides the coding tree units (CTUs) into CUs according to a quad-tree structure. That is, the video coder divides the CTUs and CUs into four equal, non-overlapping squares, and each node in the quad-tree has either zero or four child nodes. Nodes without child nodes are sometimes called "leaf nodes," and the CUs of such leaf nodes may contain one or more PUs and / or one or more TUs. The video coder may further divide the PUs and TUs. For example, in HEVC, the residual quad-tree (RQT) represents a division of the TUs. In HEVC, PUs represent intra-predicted data, and TUs represent residual data. Intra-predicted CUs contain intra-predicted information, such as intra-mode indications.

[0036]

[0045] As another example, a video encoder 200 and a video decoder 300 may be configured to operate according to VVC. According to VVC, a video coder (such as the video encoder 200) divides a picture into multiple coding tree units (CTUs). The video encoder 200 may divide 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 division types, such as the separation between CUs and PUs and TUs in HEVC. The QTBT structure includes two levels: a first level divided according to quad-tree division and a second level divided according to binary tree division. The root node of the QTBT structure corresponds to a CTU. The leaf nodes of the binary tree correspond to coding units (CUs).

[0037]

[0046] In an MTT partitioning structure, blocks can be partitioned using quad-tree (QT) partitions, binary-tree (BT) partitions, and one or more types of triple-tree (TT) (also called terminally-tree (TT)) partitions. A triple-tree or terminally-tree partition is a partition in which a block is split into three sub-blocks. In some examples, a triple-tree or terminally-tree partition divides a block into three sub-blocks without splitting the original block through a center. The partitioning types in an MTT (e.g., QT, BT, and TT) can be symmetric or asymmetric.

[0038]

[0047] When operating according to the AV1 codec, the video encoder 200 and video decoder 300 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 128×128 lumasamps or 64×64 lumasamps. However, in successor video coding formats (e.g., AV2), a superblock may be defined by a different (e.g., larger) lumasamp size. In some examples, the superblock is the top level of a block quad tree. The video encoder 200 may further subdivide the superblock into smaller coding blocks. The video encoder 200 may subdivide the superblock and other coding blocks into smaller blocks using square or non-square divisions. Non-square blocks may include N / 2×N, N×N / 2, N / 4×N, and N×N / 4 blocks. The video encoder 200 and video decoder 300 may perform separate prediction and transformation processes for each coding block.

[0039]

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

[0040]

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

[0041]

[0050] The video encoder 200 and video decoder 300 may be configured to use a quad-tree division, a QTBT division, an MTT division, a superblock division, or other divisional structure.

[0042]

[0051] In some examples, the CTU includes a coding tree block (CTB) of a lumen sample, two corresponding CTBs of a chroma sample for a picture with three sample arrays, or a CTB of a sample for a monochrome picture, or a picture coded using three separate color planes and syntax structures used to code the sample. The CTB can be an N×N block of samples, for some value N such that the division of components into the CTB is a partition. The components can be an array or a single sample from one of three arrays (lumen and two chroma) for a picture in a 4:2:0, 4:2:2, or 4:4:4 color format, or an array or a single sample of an array for a picture in a monochrome format. In some examples, the coding block is an M×N block of samples, for some values ​​M and N such that the division of the CTB into the coding block is a partition.

[0043]

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

[0044]

[0053] In some examples, a tile may be divided into multiple bricks, each of which may contain one or more CTU rows. Tiles that are not divided into multiple bricks are sometimes also called bricks. However, bricks that are a true subset of tiles are sometimes not called tiles. Bricks in a picture can also be placed in a slice. A slice can be an integer number of bricks in a picture that may be contained exclusively within a single Network Abstraction Layer (NAL) unit. In some examples, a slice may contain either several complete tiles or only a contiguous sequence of complete bricks of a single tile.

[0045]

[0054] This disclosure may use "N×N (NxN)" and "N×N (N by N)" interchangeably to refer to the sample dimensions of a block (such as a CU or other video block) with respect to vertical and horizontal dimensions, for example, 16×16 samples or 16×16 samples. Generally, a 16×16 CU has 16 samples vertically (y=16) and 16 samples horizontally (x=16). Similarly, an N×N CU generally has N samples vertically and N samples horizontally, where N represents a non-negative integer. Samples in a CU can be arranged in rows and columns. Furthermore, a CU does not necessarily have to have the same number of samples horizontally as vertically. For example, a CU may have N×M samples, where M is not necessarily equal to N.

[0046]

[0055] The video encoder 200 encodes video data for the CU, representing prediction and / or residual information, as well as other information. The prediction information indicates how the CU should be predicted in order to form a prediction block for the CU. The residual information generally represents the sample-by-sample difference between the CU sample before encoding and the prediction block.

[0047]

[0056] To predict a CU, the video encoder 200 may generally form prediction blocks for the CU through inter-prediction or intra-prediction. Inter-prediction generally refers to predicting the CU from data of a previously coded picture, while intra-prediction generally refers to predicting the CU from data of the same picture that was coded before. To perform inter-prediction, the video encoder 200 may generate prediction blocks using one or more motion vectors. The video encoder 200 may generally perform motion search to identify a reference block that perfectly matches the CU with respect to the difference between the CU and the reference block. The video encoder 200 may compute a difference metric using absolute difference sum (SAD), squared difference sum (SSD), mean absolute difference (MAD), mean squared difference (MSD), or other such difference calculations to determine whether the reference block currently perfectly matches the CU. In some examples, the video encoder 200 may predict the current CU using unidirectional or bidirectional prediction.

[0048]

[0057] Some examples of VVC also offer an affine motion compensation mode, which can be considered an interpredictive mode. In affine motion compensation mode, the video encoder 200 may determine two or more motion vectors representing non-translational motion, such as zooming in or out, rotation, perspective motion, or other anomalous motion types.

[0049]

[0058] To perform intra-prediction, the video encoder 200 may select an intra-prediction mode to generate a prediction block. Several examples of VVCs offer 67 intra-prediction modes, including various directional modes, as well as planar and DC modes. Generally, the video encoder 200 selects an intra-prediction mode that describes adjacent samples to the current block (e.g., a block of CUs) from which samples of the current block should be predicted. Such samples could generally be above, to the upper left, or to the left of the current block in the same picture as the current block, assuming the video encoder 200 codes CTUs and CUs in raster scan order (left to right, top to bottom).

[0050]

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

[0051]

[0060] AV1 includes two common techniques for encoding and decoding coding blocks of video data. The two common 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 the current frame of video data using the intra-prediction mode, the video encoder 200 and video decoder 300 do not use video data from other frames of the video data. In most intra-prediction modes, the video encoder 200 encodes the block of the current frame based on the difference between the sample value in the current block and the predicted value that will be generated from a reference sample in the same frame. The video encoder 200 determines the predicted value that will be generated from the reference sample based on the intra-prediction mode.

[0052]

[0061] Following predictions such as intra-prediction or inter-prediction of a block, the video encoder 200 may compute residual data for the block. Residual data, such as residual blocks, represents the sample-by-sample difference between the block and the predicted block for the block, formed using the corresponding prediction mode. The video encoder 200 may apply one or more transformations to the residual blocks to produce data that has been transformed in the transformation region rather than the sample region. For example, the video encoder 200 may apply a discrete cosine transform (DCT), integer transform, wavelet transform, or a conceptually similar transform to the residual video data. Furthermore, following the first transformation, the video encoder 200 may apply a quadratic transform such as a mode-dependent non-separable secondary transform (MDNSST), signal-dependent transform, or Carunen-Löwe ​​transform (KLT). The video encoder 200 produces transformation coefficients following the application of one or more transformations.

[0053]

[0062] As described above, following any transformation to produce the transformation coefficients, the video encoder 200 may perform quantization of the transformation coefficients. Quantization generally refers to the process of further compression in which the transformation coefficients are quantized to reduce the amount of data used to represent them as much as possible. By performing the quantization process, the video encoder 200 may reduce the bit depth associated with some or all of the transformation coefficients. For example, the video encoder 200 may round an n-bit value to an m-bit value during quantization, where n is greater than m. In some examples, to perform quantization, the video encoder 200 may perform a bitwise right shift of the value to be quantized.

[0054]

[0063] Following quantization, the video encoder 200 may scan the transformation coefficients to create a one-dimensional vector from a two-dimensional matrix containing the quantized transformation coefficients. The scan may be designed to place higher-energy (and therefore lower-frequency) transformation coefficients at the beginning of the vector and lower-energy (and therefore higher-frequency) transformation coefficients at the end. In some examples, the video encoder 200 may utilize a predefined scan order to scan the quantized transformation coefficients to create a serialized vector, and then entropy-encode the quantized transformation coefficients of the vector. In other examples, the video encoder 200 may perform adaptive scanning. After scanning the quantized transformation coefficients to form a one-dimensional vector, the video encoder 200 may entropy-encode the one-dimensional vector, for example, according to context-adaptive binary arithmetic coding (CABAC). The video encoder 200 may also entropy-encode values ​​for syntax elements describing metadata related to the encoded video data for use by the video decoder 300 when decoding the video data.

[0055]

[0064] When encoding the transformation coefficients of a transformation block, the video encoder 200 may encode values ​​for syntax elements, for example, including a significant transformation coefficient flag (indicating whether the coefficient has an absolute value greater than 0), a greater than one flag (indicating whether the coefficient has an absolute value greater than 1), a greater than two flag (indicating whether the coefficient has an absolute value greater than 2), a remainder value (representing the amount by which the absolute value of the coefficient exceeds 2), and a sign flag (indicating whether the value for the coefficient is positive or negative).

[0056]

[0065] When encoding the residual value of the current coefficient, the video encoder 200 may binarize the residual value using a rice parameter. According to the technique of the present disclosure, in order to determine the rice parameter, the video encoder 200 may calculate the sum of the absolute values ​​of adjacent coefficients with respect to the current coefficient. For example, the video encoder 200 may calculate the absolute values ​​of the coefficient to the right of the current coefficient, the coefficient two positions to the right, the coefficient below, the coefficient two positions below, and the coefficients below and to the right, as shown in Figure 2 below. The video encoder 200 may then add each of the calculated absolute values ​​to form a value for the sum of the absolute values. The video encoder 200 may then determine the bit depth and / or at least one of the slice types for the slice containing the current block.

[0057]

[0066] The video encoder 200 may then calculate a base-level offset value according to the bit depth and / or slice type, for example, using equation (1), which is described in more detail below. The video encoder 200 may then use the base-level offset value to calculate a normalized value for the sum of absolute values. For example, the video encoder 200 may calculate a normalized value using equation (2), which is described in more detail below. The video encoder 200 may then derive the Rice parameter using the normalized value for the local sum of absolute values, for example, according to Table 1, which is described in more detail below. The video encoder 200 may then use the Rice parameter to form a Golomb-Rice code for the normalized value for the sum of absolute values.

[0058]

[0067] To perform CABAC, the video encoder 200 may assign a context within the context model to the symbol to be transmitted. The context may relate, for example, to whether the adjacent value of the symbol is zero. Probability decisions may be based on the context assigned to the symbol. In the case of the conversion coefficients described in the example above, the symbol may correspond to one of the bits (bins) of the Golombrice code.

[0059]

[0068] The video encoder 200 may further generate syntax data for the video decoder 300, such as block-based syntax data, picture-based syntax data, and sequence-based syntax data, in other syntax data such as picture headers, block headers, slice headers, or sequence parameter sets (SPS), picture parameter sets (PPS), or video parameter sets (VPS). The video decoder 300 may similarly decode such syntax data to determine how the corresponding video data should be decoded.

[0060]

[0069] In this way, the video encoder 200 can generate a bitstream containing encoded video data, for example, a bitstream containing syntax elements that describe the division of a picture into blocks (e.g., CUs) and predictive and / or residual information about the blocks. Finally, the video decoder 300 can receive the bitstream and decode the encoded video data.

[0061]

[0070] Generally, the video decoder 300 performs the reverse process of what the video encoder 200 did to decode the encoded video data of the bitstream. For example, the video decoder 300 may decode values ​​for syntax elements of the bitstream using CABAC in a substantially similar manner to, but in reverse, the CABAC encoding process of the video encoder 200. The syntax elements may define partitioning information for partitioning a picture into CTUs, and partitions for each CTU, following a corresponding partitioning structure such as a QTBT structure, in order to define the CUs of the CTUs. The syntax elements may further define prediction and residual information for blocks of video data (e.g., CUs).

[0062]

[0071] Residual information may be represented, for example, by quantized transformation coefficients. The video decoder 300 may dequantize and inverse transform the quantized transformation coefficients of a block in order to reconstruct the residual block for the block. The video decoder 300 uses a signaled prediction mode (intra or inter-prediction) and associated prediction information (for example, motion information for inter-prediction) to form a prediction block for the block. The video decoder 300 may then combine the prediction block and the residual block (sample by sample) to reconstruct the original block. The video decoder 300 may perform additional processing, such as performing a deblocking process to reduce visual artifacts along the block boundaries.

[0063]

[0072] According to the techniques of the present disclosure, the video decoder 300 may receive an entropy-encoded value for the current coefficient of a transformation block. The video decoder 300 may entropy-decode the entropy-encoded value to form a Golomb-Rice code representing the value of the current coefficient. The video decoder 300 may calculate the sum of the local absolute values ​​of adjacent coefficients with respect to the current coefficient. The video decoder 300 may also calculate a base-level offset value, for example, using equation (1) described below. The video decoder 300 may use the base-level offset value to calculate a normalized value for the sum of absolute values, for example, using equation (2) described below. The video decoder 300 may then determine the Rice parameter from the normalized value, for example, using Table 1 described below. The video decoder 300 may then binarize the value for the current coefficient (e.g., the absolute residual value) using the Rice parameter and from the Golomb-Rice code. The video decoder 300 can reconstruct the current coefficient from the absolute residual value and other decoded values ​​for the current coefficient, such as the sign value, significance transformation coefficient value, a value greater than one, and a value greater than two.

[0064]

[0073] This disclosure may generally refer to “signaling” certain information, such as syntax elements. The term “signaling” may generally refer to the communication of values ​​about syntax elements and / or other data used to decode encoded video data. That is, the video encoder 200 may signal values ​​about syntax elements in the bitstream. Generally, signaling refers to generating values ​​in the bitstream. As described above, the source device 102 may transfer the bitstream to the destination device 116 in substantially real time, or non-real time, such as when storing the syntax elements in the storage device 112 for later retrieval by the destination device 116.

[0065]

[0074] Figure 2 is a conceptual diagram showing an example of adjacent coefficients to the current coefficients that can be used to calculate the sum of local absolute values ​​(locSumAbs). In the current design of VVC, the Rice parameters for residual coding (RRC) are typically derived using a lookup table, along with considering the coefficient values ​​of adjacent transformed coefficients that follow a template. The adjacent coefficients shaded in gray in Figure 2 represent templates for the current coefficients shaded in black in Figure 2.

[0066]

[0075] In particular, Figure 2 shows the current block 130, which contains various transformation coefficients. The current block 130 includes the current coefficient 132 and adjacent coefficients 134A to 124E (adjacent coefficient 134). With respect to the position of the current coefficient 132, adjacent coefficient 134A represents the adjacent coefficient to the right, adjacent coefficient 134B represents the adjacent coefficient two positions to the right, adjacent coefficient 134C represents the adjacent coefficient to the lower right, adjacent coefficient 134D represents the adjacent coefficient below, and adjacent coefficient 134E represents the adjacent coefficient two positions below.

[0067]

[0076] The videocoder may calculate the sum of local absolute values ​​(locSumAbs), for example, the sum of the absolute values ​​of the adjacent coefficient 134 with respect to the current coefficient 132. According to VVC, the videocoder calculates the value of locSumAbs as the sum of the absolute values ​​of the five available adjacent coefficients, as in the case of Figure 2. According to an example of VVC, the videocoder then normalizes the value of locSumAbs (using subtraction and clipping) according to the following formula:

[0068]

number

[0069]

[0077] Next, according to VVC, the video coder derives the Rice parameters using the normalized values ​​of locSumAbs, using Table 1 below.

[0070] [Table 1]

[0071]

[0078] In VVC, the Rice parameter range is constrained to be between 0 and 3, including both endpoints.

[0072]

[0079] According to the techniques of this disclosure, a video coder may calculate a base-level offset according to equation (1), which is described in more detail below. That is, the video coder may calculate a base-level offset value according to the bit depth and / or the slice type for the slice containing the current block 130.

[0073]

[0080] Figure 3 is a graph showing the empirical histogram 136 of coded conversion coefficients for a 16-bit test sequence of video data.

[0074]

[0081] Figure 4 is a graph 140 showing the relationship between the codeword length generated during entropy coding for coefficient values ​​and a given Rice parameter.

[0075]

[0082] The Rice parameter has been extensively tested for encoding 8-bit or 10-bit depth video sources. In one exemplary design, the Rice parameter value depends on the locSumAbs value and is limited to a range of 0 to 3 by clipping. When the bit depth of the input video is increased, or extended precision is enabled, or the quantization parameter is set very low, the range of coefficients and, therefore, the locSumAbs value can increase significantly. In such cases, the current VVC range of acceptable Rice parameters is insufficient because it would require the use of long codewords, e.g., 32-bit codewords, for coded coefficients of large values.

[0076]

[0083] Figures 3 and 4 provide a visualization of the resulting problems. In particular, Figure 3 shows a histogram of coded coefficients (in the form of powers of 2) for a 16-bit signal. Figure 4 shows the codeword length produced by the VVC entropy coding method for coded values. It can be seen from Figure 4 that limiting the normative range of the Rice parameter to 3 (as defined in VVC) results in a significant increase in codeword length for coded values ​​greater than 10. This problem can be solved by allowing larger values ​​for the Rice parameter for larger coefficients.

[0077]

[0084] In one design (CE1.1 of the JVET-U meeting) to address the limitations of the current VVC Rice parameter derivation at various input bit depths of video, and thus improve compression efficiency, the supported range of the Rice parameter can be extended from 3 in VVC to a larger number, such as 16, which will provide a more efficient binarization process and result in a lower number of bits for larger values ​​of the conversion coefficient.

[0078]

[0085] The value of localSumbAbs may be scaled / normalized to handle bit depth increments or dynamic ranges of conversion coefficients before being used to derive the Rice parameter, for example, according to Equation 1517 of the VVC specification. The amount of the scaling factor may depend on the output of a template derivation calculated to show the local activity of the localSumbAbs value, or on the set of syntax elements or constructed values ​​signaled in the bitstream.

[0079]

[0086] The VVC video encoder may compare the determined value of localSumAbs with a constructed set of thresholds Tx={Tid} to identify the dynamic range ID for the dynamic range containing that value. The video coder may then scale and / or normalize the value of localSumAbs by a scalar normShift of values ​​from a given set of constructed Rx={Rid} determined by the range ID. The video coder may then use the normalized localSumAbs to derive the Rice parameters using a predefined lookup table, for example, the current lookup table in VVC, Table 128. Once the value of localSumbAbs is normalized in the first step of the proposed design, the Rice parameters may be derived from a predefined table, for example, Table 128, and finally modified by adding an offset equal to Rid to extend the dynamic range of the Rice parameter range.

[0080]

[0087] The set of threshold Tx and scaler Rx can be defined as follows:

[0081]

[0088]

[0082]

number

[0083]

[0089]

[0084]

number

[0085]

[0090] The values ​​of array Tx may be restricted to powers of 2, and in other embodiments, their values ​​may be derived by a power of 2 (2^x) and converted to such values ​​through a limited number of operations, such as offset, scaling, or right / left shift.

[0086]

[0091] The size of the array can be equal to N, where N is a positive integer greater than the lower boundary, e.g., >1 or >2, and less than the upper boundary, e.g., 9 or 5. In some embodiments, the size of the Rx array is only one entry larger than the array of Tx. In some embodiments, the sizes of the Tx and Rx arrays can be limited to 4.

[0087]

[0092] In some examples, the relevant Rice parameter derivation part in VVC can be modified as follows, and the size of the constructed array is equal to 4. (The following is within the box) 9.3.3.2 Rice parameter derivation process for abs_remainder[] and dec_abs_level[] The inputs to this process are the base level, the color component index cIdx, the lumen location (x0, y0) specifying the top-left sample of the current transformation block relative to the top-left sample of the current picture, the current coefficient scan location (xC, yC), the binary logarithm of the transformation block width log2TbWidth, and the binary logarithm of the transformation block height log2TbHeight. The output of this process is the rice parameter cRiceParam. Assuming an array AbsLevel[x][y] for a transformation block having component index cIdx and upper-left luma location (x0, y0), the variable locSumAbs is derived as specified by the following pseudocode process.

[0088]

number

[0089] g_riceT and g_riceShift are defined as follows:

[0090]

number

[0091] Assuming the variable locSumAbs, the rice parameter cRiceParam is derived as specified in Table 128. cRiceParam will then be improved as follows:

[0092]

number

[0093] (End of document within the frame)

[0093] In order to extend the range of the locSumAbs parameter, CE1.2 of the U meeting proposes that if locSumAbs exceeds a certain threshold, the value locSumAbs is scaled by a shift so that the scaled value fits into the tolerance range of Table 128 of the VVC specification without clipping. Subsequently, the output of Table 128 is adjusted by incrementing by the shift value if the scaling process was performed for a given locSumAbs value.

[0094]

[0094] The encoder (for example, the video encoder 200) may select a value for the syntax element sh_scale_rice, which can take the value 1 or 2.

[0095]

[0095]

[0096]

number

[0097]

[0096]

[0098]

number

[0099]

[0097] The value sh_scale_rice used is signaled as a syntax element in the slice header and derived on the encoder side as a function of the QP value.

[0100]

[0098] The specification text for VVC may be as follows: A sps_high_bit_depth equal to 1 specifies that the sh_rice_parameter syntax element may be present in the slice header to enable a high-bit-depth mode for rice parameters for binarization of abs_remaining[] and dec_abs_level. A sps_high_bit_depth equal to 0 specifies that the sh_rice_parameter syntax element is not present in the slice header and a high-bit-depth mode for rice parameter derivation cannot be enabled. When it is not present, the value of sps_high_bit_depth is inferred to be equal to 0. 7.3.7 Slice Header Syntax

[0101] [Table 2]

[0102] sh_scale_rice specifies the scale value used for deriving the rice parameter, and the value of sh_scale_rice should be within the range of 1 to 2, including both endpoints. If sh_scale_rice does not exist, it is inferred to be equal to 0. (The following is within the box) 9.3.3.2 Rice parameter derivation process for abs_remainder[] and dec_abs_level[] The inputs to this process are the base level, the color component index cIdx, the lumen location (x0, y0) specifying the top-left sample of the current transformation block relative to the top-left sample of the current picture, the current coefficient scan location (xC, yC), the binary logarithm of the transformation block width log2TbWidth, and the binary logarithm of the transformation block height log2TbHeight. The output of this process is the rice parameter cRiceParam. Assuming an array AbsLevel[x][y] for a transformation block having component index cIdx and upper-left luma location (x0, y0), the variable locSumAbs is derived as specified by the following pseudocode process.

[0103]

number

[0104] The variable `shift` is derived as follows:

[0105]

number

[0106] The variable localSumAbs is updated as follows:

[0107]

number

[0108] Assuming the variable locSumAbs, the rice parameter cRiceParam is derived as specified in Table 128. cRiceParam will then be improved as follows:

[0109]

number

[0110] (End of document within the frame)

[0099] The RRC method described above can be extended using a history of the Rice parameters used, as described below.

[0111]

[0100] A single counter is used for each color component, and StatCoeff[3] is updated once per TU from a first non-zero Golombrice-coded conversion coefficient (abs_remainder[] or dec_abs_level[]).

[0112]

[0101] When the first non-zero Golombrice-coded conversion coefficient in TU is coded as abs_remainder, the history counter (StatCoeff) for the color component cIdx is updated as follows:

[0113]

number

[0114]

[0102] When the first non-zero Golombrice-coded conversion coefficient in TU is coded as abs_remainder, the history counter for the color component cIdx is updated as follows:

[0115]

number

[0116]

[0103] The history counter StatCoeff[3] can be reset at the CTU level with a default value, or the history can be propagated between different CTUs.

[0117]

[0104] The history rice parameter value is used in template derivation, and the implementation of this method in Section 9.3.3.2 is an excerpt of the VVC specification text shown for Section 9.3.3.2, where the text highlighted in green relates to changes from CE-1.2 and the text highlighted in yellow relates to classifications used in CE-1.4. The variable g_historyValue is derived from the history counter associated with the current color component id, prior to the coding of the current TU.

[0118]

number

[0119] (The following is within the box) 9.3.3.2 Rice parameter derivation process for abs_remainder[] and dec_abs_level[] The inputs to this process are the base level, the color component index cIdx, the lumen location (x0, y0) specifying the top-left sample of the current transformation block relative to the top-left sample of the current picture, the current coefficient scan location (xC, yC), the binary logarithm of the transformation block width log2TbWidth, and the binary logarithm of the transformation block height log2TbHeight. The output of this process is the rice parameter cRiceParam. Assuming an array AbsLevel[x][y] for a transformation block having component index cIdx and upper-left luma location (x0, y0), the variable locSumAbs is derived as specified by the following pseudocode process.

[0120]

number

[0121] The variable `shift` is derived as follows:

[0122]

number

[0123] The variable localSumAbs is updated as follows:

[0124]

number

[0125] Assuming the variable locSumAbs, the rice parameter cRiceParam is derived as specified in Table 128. cRiceParam will then be improved as follows:

[0126]

number

[0127] (End of document within the frame)

[0105] The video encoder 200 and the video decoder 300 may be configured according to the techniques of the present disclosure, as described below. These techniques include modifications to the techniques described above.

[0128]

[0106] In some examples, in the case of the local base slice derivation technique described above, the video encoder 200 and video decoder 300 may derive a base level offset as a function of the input signal bit depth and / or slice type, as shown below, and use the baseLevel offset value to scale the locSumAbs value.

[0129]

[0107] In some examples, the video encoder 200 and the video decoder 300 may derive the baseLevelOffset as follows:

[0130]

number

[0131]

[0108] In equation (1), the question mark operator (?) represents an expression of the form <condition>?X:Y, where if <condition> is true, the value of X is returned, but if <condition> is false, the value of Y is returned. The baseLevelOffset value represents the base level offset, bitDepth represents the bit depth of the video bitstream, T is the threshold, and P1, P2, P3, and P4 are values ​​that are predetermined or can be signaled in the bitstream.

[0132]

[0109] The video encoder 200 and video decoder 300 may use a base-level offset value to normalize localSumAbs as follows:

[0133]

number

[0134]

[0110] Generally, T represents a threshold, and the P1, P2, P3, and P4 values ​​represent integer values. In some examples, T=12, P1=5, P2=10, P3=6, and P4=20. In some examples, T=12, P1=5, P2=10, P3=10, and P4=20. Other values ​​for T, P1, P2, P3, and P4 may also be used. T, P1, P2, P3, and P4 may be predefined, signaled in the bitstream, or derived based on various criteria.

[0135]

[0111] In some cases, in the case of the history-based rice derivation technique described above, the video encoder 200 and video decoder 300 may store the status of the history counter StatCoeff[cIdx] across several blocks (e.g., several CTUs). As an addition or alternative, the video encoder 200 and video decoder 300 may derive the ScaleRice parameter (replacing the explicitly signaled sh_scale_rice syntax element) from the current status of the StatCoeff[] counter at the block level, e.g., the CTU level. Thus, the video encoder 200 and video decoder 300 do not need to explicitly signal the sh_rice_init syntax element.

[0136]

[0112] In some examples, the video encoder 200 and video decoder 300 may derive the ScaleRice parameter value by comparing the status of StatCoeff[] with a threshold and by specifying an integer value for the parameter within a range of integer values. One such example of derivation is shown below.

[0137]

number

[0138]

[0113] In some examples, T=4, P2=2, and P1=1.

[0139]

[0114] In some examples, the video encoder 200 and the video decoder 300 may independently derive the parameter ScaleRice for each color component (e.g., lumens, blue chroma, and red chroma).

[0140]

[0115] In some examples, when the video encoder 200 and video decoder 300 derive a value for the ScaleRice parameter, they may take into account values ​​for history counters for two or more (e.g., all) color components through an aggregation function, for example, a weighted function across the color components, as shown below.

[0141]

number

[0142]

[0116] In some examples, w0=2, w1=1, and w2=1.

[0143]

[0117] In some examples, the video encoder 200 and video decoder 300 may derive the parameter ScaleRice at the block level, for example at the CTU, TU, or subTU level. The video encoder 200 and video decoder 300 may use the ScaleRice parameter when decoding data from blocks of data that have been coded later. Alternatively, the video encoder 200 and video decoder 300 may use the derived ScaleRice value in a manner delayed by a certain block size, for example, to decode a block after the next block.

[0144]

[0118] Therefore, checks for the if(sps_high_bit_depth) and sh_scale_rice syntax elements can be removed from the syntax table.

[0145]

[0119] In some examples, the video encoder 200 and video decoder 300 may derive the ScaleRice value through the process described above, following the initialization of StatCoeff with default values ​​or signaled values.

[0146]

[0120] Figure 5 is a block diagram showing an exemplary video encoder 200 capable of implementing the techniques of this disclosure. Figure 5 is provided for illustrative purposes and should not be considered to limit the techniques broadly illustrated and described in this disclosure. For illustrative purposes, this disclosure describes the video encoder 200 according to the techniques of VVC (ITU-T H.266 in development) and HEVC (ITU-T H.265). However, the techniques of this disclosure may be implemented by video encoding devices configured to other video coding standards and video coding formats, such as AV1 and successors to the AV1 video coding format.

[0147]

[0121] In the example of Figure 5, the video encoder 200 includes a video data memory 230, a mode selection unit 202, a residual generation unit 204, a conversion processing unit 206, a quantization unit 208, an inverse quantization unit 210, an inverse conversion processing unit 212, a reconstruction unit 214, a filter unit 216, a decoded picture buffer (DPB) 218, and an entropy coding unit 220. Any or all of the video data memory 230, the mode selection unit 202, the residual generation unit 204, the conversion processing unit 206, the quantization unit 208, the inverse quantization unit 210, the inverse conversion processing unit 212, the reconstruction unit 214, the filter unit 216, the DPB 218, and the entropy coding unit 220 may be implemented in one or more processors or processing circuits. For example, a unit of the video encoder 200 may be implemented as one or more circuit or logic elements, as part of a hardware circuit, or as part of a processor, ASIC, or FPGA. Furthermore, the video encoder 200 may include additional or alternative processors or processing circuits to perform these and other functions.

[0148]

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

[0149]

[0123] In this disclosure, references to the video data memory 230 should not be interpreted as being limited to memory inside the video encoder 200 unless specifically described so, or as being limited to memory outside the video encoder 200 unless specifically described so. Rather, references to the video data memory 230 should be understood as reference memory that stores video data that the video encoder 200 receives for encoding (for example, video data for the current block to be encoded). Memory 106 in Figure 1 may also provide temporary storage of outputs from various units of the video encoder 200.

[0150]

[0124] The various units in Figure 5 are shown to help understand the operations performed by the video encoder 200. The units may be implemented as fixed-function circuits, programmable circuits, or a combination thereof. Fixed-function circuits refer to circuits that provide a specific function and are preset in terms of the operations they may perform. Programmable circuits refer to circuits that can be programmed to perform various tasks and to provide flexible functionality in the operations they may perform. For example, a programmable circuit may run software or firmware that operates the programmable circuit in a manner defined by software or firmware instructions. Fixed-function circuits may run software instructions (for example, to receive or output parameters), but the type of operation performed by a fixed-function circuit is generally immutable. In some examples, one or more of the units may be separate circuit blocks (fixed-function or programmable), and in some examples, one or more of the units may be integrated circuits.

[0151]

[0125] The video encoder 200 may include a programmable core formed from an arithmetic logic unit (ALU), an basic function unit (EFU), digital circuits, analog circuits, and / or programmable circuits. In an example where the operation of the video encoder 200 is carried out using software executed by the programmable circuits, memory 106 (Figure 1) may store instructions (e.g., object code) of the software that the video encoder 200 receives and executes, or another memory (not shown) within the video encoder 200 may store such instructions.

[0152]

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

[0153]

[0127] The mode selection unit 202 includes a motion estimation unit 222, a motion compensation unit 224, and an intra-prediction unit 226. The mode selection unit 202 may include additional functional units for performing video prediction according to other prediction modes. For example, the mode selection unit 202 may include a pallet unit, an intra-block copy unit (which may be part of the motion estimation unit 222 and / or the motion compensation unit 224), an affine unit, a linear model (LM) unit, and the like.

[0154]

[0128] The mode selection unit 202 generally coordinates multiple coding paths to test combinations of coding parameters and the rate-distortion values ​​obtained for such combinations. The coding parameters may include the division of the CTU to the CU, the prediction mode for the CU, the transformation type for the residual data of the CU, the quantization parameters for the residual data of the CU, and so on. The mode selection unit 202 may ultimately select a combination of coding parameters that has a rate-distortion value that is better than other tested combinations.

[0155]

[0129] The video encoder 200 divides the picture retrieved from the video data memory 230 into a series of CTUs and may encapsulate one or more CTUs within a slice. The mode selection unit 202 may divide the CTUs of a picture according to a tree structure, such as the MTT structure, QTBT structure, superblock structure, or quadtree structure described above. As described above, the video encoder 200 may form one or more CUs from dividing the CTUs according to a tree structure. Such CUs are sometimes generally referred to as “video blocks” or “blocks”.

[0156]

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

[0157]

[0131] The motion estimation unit 222 may form one or more motion vectors (MVs) that define the position of a reference block in a reference picture relative to the position of a current block in a current picture. The motion estimation unit 222 may then provide the motion vectors to the motion compensation unit 224. For example, in unidirectional interpretation, the motion estimation unit 222 may provide a single motion vector, while in bidirectional interpretation, the motion estimation unit 222 may provide two motion vectors. The motion compensation unit 224 may then use the motion vectors to generate predicted blocks. For example, the motion compensation unit 224 may use the motion vectors to extract data for a reference block. As another example, if the motion vectors have partial sample accuracy, the motion compensation unit 224 may interpolate values ​​for the predicted block according to one or more interpolation filters. Furthermore, in bidirectional interpretation, the motion compensation unit 224 may extract data for two reference blocks identified by their respective motion vectors and combine the extracted data, for example, through sample-wise averaging or weighted averaging.

[0158]

[0132] When operating according to the AV1 video coding format, the motion estimation unit 222 and the motion compensation unit 224 may be configured to encode coding blocks of video data (for example, both lumane coding blocks and chromane coding blocks) using translational motion compensation, affine motion compensation, overlapping block motion compensation (OBMC), and / or compound inter-intra prediction.

[0159]

[0133] As another example, for intra-prediction, or intra-prediction coding, the intra-prediction unit 226 may generate a prediction block from samples adjacent to the current block. For example, in directional mode, the intra-prediction unit 226 may mathematically combine the values ​​of adjacent samples to produce a prediction block and populate these calculated values ​​in a direction defined across the current block. As another example, in DC mode, the intra-prediction unit 226 may calculate the average of adjacent samples relative to the current block and generate a prediction block so that each sample of the prediction block contains this obtained average.

[0160]

[0134] When operating according to the AV1 video coding format, the intra prediction unit 226 may be configured to encode coding blocks of video data (e.g., both lumane coding blocks and chromane coding blocks) using directional intra prediction, non-directional intra prediction, recursive filter intra prediction, chroma-from-luma (CFL) prediction, intra-block copy (IBC), and / or color palette modes. The mode selection unit 202 may include additional functional units for performing video prediction according to other prediction modes.

[0161]

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

[0162]

[0136] In an example where the mode selection unit 202 divides a CU into PUs, each PU may be associated with a lumar prediction unit and a corresponding chroma prediction unit. The video encoder 200 and video decoder 300 may support PUs of various sizes. As shown above, the size of a CU may refer to the size of the lumar coding block of the CU, and the size of a PU may refer to the size of the lumar prediction unit of the PU. Assuming that the size of a particular CU is 2N × 2N, the video encoder 200 may support PU sizes of 2N × 2N or N × N for intra prediction, and symmetric PU sizes of 2N × 2N, 2N × N, N × 2N, N × N, or similar for inter prediction. The video encoder 200 and video decoder 300 may also support asymmetric divisions for PU sizes of 2N × nU, 2N × nD, nL × 2N, and nR × 2N for inter prediction.

[0163]

[0137] In the example where the mode selection unit 202 does not further subdivide the CUs into PUs, each CU may be associated with a ruma coding block and a corresponding chroma coding block. As described above, the size of a CU may refer to the size of the ruma coding block of the CU. The video encoder 200 and video decoder 300 may support CU sizes of 2N×2N, 2N×N, or N×2N.

[0164]

[0138] In some examples, in other video coding techniques such as intra-block copy mode coding, affine mode coding, and linear model (LM) mode coding, the mode selection unit 202 generates a predicted block for the current block being coded through the respective unit associated with the coding technique. In some examples, such as palette mode coding, the mode selection unit 202 may not generate a predicted block, but instead generate syntax elements indicating the form in which the block should be reconstructed based on the selected palette. In such modes, the mode selection unit 202 may provide these syntax elements to be coded to the entropy coding unit 220.

[0165]

[0139] As described above, the residual generation unit 204 receives video data for the current block and the corresponding predicted block. The residual generation unit 204 then generates a residual block for the current block. To generate the residual block, the residual generation unit 204 calculates the sample-by-sample difference between the predicted block and the current block.

[0166]

[0140] The transformation processing unit 206 applies one or more transformations to the residual block to generate blocks of transformation coefficients (referred to herein as “transformation coefficient blocks”). The transformation processing unit 206 may apply various transformations to the residual block to form the transformation coefficient blocks. For example, the transformation processing unit 206 may apply a discrete cosine transform (DCT), a directional transform, a Carunenlebe transform (KLT), or a conceptually similar transform to the residual block. In some examples, the transformation processing unit 206 may perform multiple transformations on the residual block, such as linear and quadratic transformations, such as a rotation transform. In some examples, the transformation processing unit 206 does not apply any transformations to the residual block.

[0167]

[0141] When operating according to AV1, the transformation processing unit 206 may apply one or more transformations to the residual block to generate blocks of transformation coefficients (referred to herein as “transformation coefficient blocks”). The transformation processing unit 206 may apply various transformations to the residual block to form the transformation coefficient blocks. For example, the transformation processing unit 206 may apply a horizontal / vertical transformation combination that may include the discrete cosine transform (DCT), the asymmetric discrete sine transform (ADST), the inverted ADST (e.g., the reversed ADST), and the identity transform (IDTX). When using the identity transform, the transformation is skipped in either the vertical or horizontal direction. In some examples, the transformation process may be skipped.

[0168]

[0142] The quantization unit 208 may quantize the transformation coefficients in the transformation coefficient block in order to produce a quantized transformation coefficient block. The quantization unit 208 may quantize the transformation coefficients of the transformation coefficient block according to the quantization parameter (QP) value associated with the current block. The video encoder 200 may adjust the degree of quantization applied to the transformation coefficient block associated with the current block by adjusting the QP value associated with the CU (for example, via the mode selection unit 202). Quantization may result in a loss of information, and therefore the quantized transformation coefficients may have lower precision than the original transformation coefficients produced by the transformation processing unit 206.

[0169]

[0143] The inverse quantization unit 210 and the inverse transform processing unit 212 may apply inverse quantization and inverse transform, respectively, to the quantized transform coefficient block in order to reconstruct the residual block from the transform coefficient block. The reconstruction unit 214 may produce a reconstructed block corresponding to the current block (with some potential distortion) based on the reconstructed residual block and the predicted block generated by the mode selection unit 202. For example, the reconstruction unit 214 may add the samples of the reconstructed residual block to the corresponding samples from the predicted block generated by the mode selection unit 202 in order to produce the reconstructed block.

[0170]

[0144] The filter unit 216 may perform one or more filtering operations on the reconstructed block. For example, the filter unit 216 may perform a deblocking operation to reduce blocking artifacts along the edges of the CU. The operation of the filter unit 216 may be skipped in some examples.

[0171]

[0145] When operating according to AV1, the filter unit 216 may perform one or more filtering operations on the reconstructed block. For example, the filter unit 216 may perform a deblocking operation to reduce blockingness artifacts along the edges of the CU. In another example, the filter unit 216 may apply a constrained directional enhancement filter (CDEF), which may be applied after deblocking and may include the application of a non-separable nonlinear low-pass directional filter based on the estimated edge direction. The filter unit 216 may also include a loop-reconstruction filter, which may be applied after the CDEF and may include a separable symmetric normalized Wiener filter or a dual self-inductive filter.

[0172]

[0146] The video encoder 200 stores the reconstructed blocks in the DPB 218. For example, in an example where the filter unit 216 does not operate, the reconstruction unit 214 may store the reconstructed blocks in the DPB 218. In an example where the filter unit 216 operates, the filter unit 216 may store the filtered reconstructed blocks in the DPB 218. The motion estimation unit 222 and the motion compensation unit 224 may retrieve a reference picture formed from the reconstructed (and potentially filtered) blocks from the DPB 218 to interpret blocks of the picture to be encoded later. Furthermore, the intraprediction unit 226 may use the reconstructed blocks in the DPB 218 of the current picture to intrapret other blocks in the current picture.

[0173]

[0147] Generally, the entropy coding unit 220 can entropy code syntax elements received from other functional components of the video encoder 200. For example, the entropy coding unit 220 can entropy code quantized transformation coefficient blocks from the quantization unit 208. As another example, the entropy coding unit 220 can entropy code prediction syntax elements from the mode selection unit 202 (e.g., motion information for inter-prediction, or intra-mode information for intra-prediction). The entropy coding unit 220 can perform one or more entropy coding operations on syntax elements, which are another example of video data, to generate entropy coded data. For example, the entropy coding unit 220 may perform context-adaptive variable-length coding (CAVLC) operation, CABAC operation, variable-to-variable (V2V) length coding operation, syntax-based context-adaptive binary arithmetic coding (SBAC) operation, probability interval partitioned entropy (PIPE) coding operation, exponential Golomb coding operation, or another type of entropy coding operation on the data. In some examples, the entropy coding unit 220 may operate in a bypass mode in which syntax elements are not entropically coded.

[0174]

[0148] In some examples, the entropy coding unit 220 may be configured to apply any or all of the Rice parameter derivation techniques described herein when entropy coding video data, for example, values ​​for one or more syntax elements of a transformation coefficient. For example, the entropy coding unit 220 may receive a transformation block from the quantization unit 208. For each coefficient in the transformation block, the entropy coding unit 220 may code values ​​for one or more of the significant transformation coefficient syntax elements, greater than 1 syntax elements, greater than 2 syntax elements, coding syntax elements, and residual values.

[0175]

[0149] When entropy coding the residual value (or dec_abs_remainder value) among the values, the entropy coding unit 220 may first calculate the value of the local sum of absolute values ​​as the sum of the absolute values ​​of adjacent coefficients with respect to the current coefficient, for example, as described above with respect to Figure 2. The entropy coding unit 220 may then calculate the base level offset value according to the bit depth and / or slice type for the slice containing the current block, for example, according to equation (1) above. The entropy coding unit 220 may use the base level offset value to calculate a normalized value for the value of the local sum of absolute values, for example, according to equation (2) above. The entropy coding unit 220 may then calculate the Rice parameter from the normalized value, for example, according to Table 1 above. The entropy coding unit 220 may then use the Rice parameter to determine the Golomb Rice code for the residual value and entropy code each bit (bin) of the Golomb Rice code.

[0176]

[0150] The video encoder 200 may output a bitstream containing entropy-encoded syntax elements required to reconstruct the slice or block of the picture. In particular, the entropy encoding unit 220 may output a bitstream.

[0177]

[0151] According to AV1, the entropy coding unit 220 may be configured as a symbol-to-symbol adaptive multi-symbol arithmetic coder. The syntax elements in AV1 include an alphabet of N elements, and the context (e.g., a probability model) includes a set of N probabilities. The entropy coding unit 220 may store the probabilities as an n-bit (e.g., 15-bit) cumulative distribution function (CDF). The entropy coding unit 22 may perform recursive scaling using an update factor based on the alphabet size to update the context.

[0178]

[0152] The operations described above are described in relation to blocks. Such descriptions should be understood as operations for ruma-coding blocks and / or chroma-coding blocks. As described above, in some examples the ruma-coding blocks and chroma-coding blocks are the ruma and chroma components of the CU. In some examples the ruma-coding blocks and chroma-coding blocks are the ruma and chroma components of the PU.

[0179]

[0153] In some cases, the actions performed for a rumacoding block do not need to be repeated for a chromacoding block. For example, the actions for identifying the motion vector (MV) and reference picture for a rumacoding block do not need to be repeated for identifying the MV and reference picture for a chromablock. Rather, the MV for a rumacoding block may be scaled to determine the MV for a chromablock, and the reference picture may be the same. In another example, the intra-prediction process may be the same for both rumacoding and chromacoding blocks.

[0180]

[0154] Thus the video encoder 200 represents an example of a device for encoding (and decoding) video data, the device comprising a memory configured to store video data and one or more processors implemented in the circuit, the one or more processors configured to calculate the sum of the absolute values ​​of a plurality of adjacent coefficients for the current coefficient for the current block of video data, calculate a base-level offset value according to at least one of the bit depth for the video data or the slice type for the slice containing the current block, calculate a normalized value for the sum of absolute values ​​using the base-level offset value, and code the current coefficient using the normalized value for the sum of absolute values.

[0181]

[0155] Figure 6 is a block diagram showing an exemplary video decoder 300 capable of implementing the techniques of this disclosure. Figure 6 is provided for illustrative purposes and is not intended to limit the techniques broadly illustrated and described in this disclosure. For illustrative purposes, this disclosure describes the video decoder 300 in accordance with the VVC (ITU-T H.266 in development) and HEVC (ITU-T H.265) techniques. However, the techniques of this disclosure may be implemented by video coding devices configured to other video coding standards.

[0182]

[0156] In the example of Figure 6, the video decoder 300 includes a coded picture buffer (CPB) memory 320, an entropy decoding unit 302, a prediction processing unit 304, an inverse quantization unit 306, an inverse transformation processing unit 308, a reconstruction unit 310, a filter unit 312, and a decoded picture buffer (DPB) 314. Any or all of the CPB memory 320, the entropy decoding unit 302, the prediction processing unit 304, the inverse quantization unit 306, the inverse transformation processing unit 308, the reconstruction unit 310, the filter unit 312, and the DPB 314 may be implemented in one or more processors or processing circuits. For example, the units of the video decoder 300 may be implemented as one or more circuits or logic elements, as part of a hardware circuit, or as part of a processor, ASIC, or FPGA. Furthermore, the video decoder 300 may include additional or alternative processors or processing circuits to perform these and other functions.

[0183]

[0157] The prediction processing unit 304 includes a motion compensation unit 316 and an intra-prediction unit 318. The prediction processing unit 304 may include additional units for performing predictions according to other prediction modes. For example, the prediction processing unit 304 may include a pallet unit, an intra-block copy unit (which may form part of the motion compensation unit 316), an affine unit, a linear model (LM) unit, and the like. In other examples, the video decoder 300 may include more, fewer, or different functional components.

[0184]

[0158] When operating according to AV1, the compensation unit 316 may be configured to decode coding blocks of video data (e.g., both lumane and chroma coding blocks) using translational motion compensation, affine motion compensation, OBMC, and / or composite inter-intra prediction, as described above. The intra-prediction unit 318 may be configured to decode coding blocks of video data (e.g., both lumane and chroma coding blocks) using directional intra-prediction, non-directional intra-prediction, recursive filter intra-prediction, CFL, intra-block copy (IBC), and / or color palette mode, as described above.

[0185]

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

[0186]

[0160] In addition or alternatively, in some examples, the video decoder 300 may retrieve coded video data from memory 120 (Figure 1). That is, memory 120 may store data together with CPB memory 320 as described above. Similarly, memory 120 may store instructions to be executed by the video decoder 300 when some or all of the functions of the video decoder 300 are implemented in software to be executed by the processing circuit of the video decoder 300.

[0187]

[0161] The various units shown in Figure 6 are shown to help understand the operations performed by the video decoder 300. The units may be implemented as fixed-function circuits, programmable circuits, or a combination thereof. As in Figure 5, fixed-function circuits refer to circuits that provide a specific function and are preset in terms of the operations they may perform. Programmable circuits refer to circuits that can be programmed to perform various tasks and to provide flexible functionality in the operations they may perform. For example, a programmable circuit may run software or firmware that operates the programmable circuit in a manner defined by software or firmware instructions. A fixed-function circuit may run software instructions (for example, to receive or output parameters), but the type of operation that a fixed-function circuit performs is generally immutable. In some examples, one or more of the units may be separate circuit blocks (fixed-function or programmable), and in some examples, one or more of the units may be integrated circuits.

[0188]

[0162] The video decoder 300 may include a programmable core formed from an ALU, an EFU, digital circuits, analog circuits, and / or programmable circuits. In an example where the operation of the video decoder 300 is performed by software running on the programmable circuits, on-chip or off-chip memory may store instructions (e.g., object code) of the software that the video decoder 300 receives and executes.

[0189]

[0163] The entropy decoding unit 302 receives encoded video data from the CPB and can entropy decode the video data to reconstruct the syntax elements. The prediction processing unit 304, the inverse quantization unit 306, the inverse transformation processing unit 308, the reconstruction unit 310, and the filter unit 312 can generate decoded video data based on the syntax elements extracted from the bitstream.

[0190]

[0164] In some examples, the entropy decoding unit 302 may be configured to apply any or all of the Rice parameter derivation techniques described herein when entropy decoding video data, for example, values ​​for one or more syntax elements of the transformation coefficients. For example, the entropy decoding unit 302 may receive entropy encoded values ​​for one or more of the significance transformation coefficient syntax elements, syntax elements greater than 1, syntax elements greater than 2, sign syntax elements, and residual values.

[0191]

[0165] When decoding the residual value (or dec_abs_remainder value) for the current coefficient among the values, the entropy decoding unit 302 can entropically decode the Golomb Rice Code from the bitstream for the residual value of the current coefficient. The entropy decoding unit 302 can then calculate the value of the local sum of absolute values ​​as the sum of the absolute values ​​of adjacent coefficients for the current coefficient, for example, as described above with respect to Figure 2. The entropy decoding unit 302 can then calculate the base level offset value according to the bit depth and / or slice type for the slice containing the current block, for example, according to equation (1) above. The entropy decoding unit 302 can then calculate a normalized value for the value of the local sum of absolute values ​​using the base level offset value, for example, according to equation (2) above. The entropy decoding unit 302 can then calculate the Rice parameter from the normalized value, for example, according to Table 1 above. The entropy decoding unit 302 may then binarize the residual values ​​from the Golomb Rice Code using the Rice parameters. The entropy decoding unit 302 may concatenate the significance coefficient values ​​with the values ​​greater than 1, the values ​​greater than 2, and the residual values ​​in order to reconstruct the current coefficients.

[0192]

[0166] Generally, the video decoder 300 reconstructs the picture block by block. The video decoder 300 may perform the reconstruction operation individually for each block (where the block currently being reconstructed, i.e., decoded, is sometimes called the "current block").

[0193]

[0167] The entropy decoding unit 302 can entropy decode the syntax elements that define the quantized transformation coefficients of the quantized transformation coefficient block, as well as transformation information such as quantization parameters (QP) and / or (one or more) transformation mode indications. The inverse quantization unit 306 may use the QP associated with the quantized transformation coefficient block to determine the degree of quantization and, similarly, the degree of inverse quantization that the inverse quantization unit 306 should apply. The inverse quantization unit 306 may perform, for example, a bitwise left shift operation to inverse quantize the quantized transformation coefficients. The inverse quantization unit 306 may thereby form a transformation coefficient block containing the transformation coefficients.

[0194]

[0168] After the inverse quantization unit 306 has formed the transformation coefficient block, the inverse transformation processing unit 308 may apply one or more inverse transformations to the transformation coefficient block in order to generate the residual block associated with the current block. For example, the inverse transformation processing unit 308 may apply an inverse DCT, an inverse integer transformation, an inverse Carunenlebe transformation (KLT), an inverse rotation transformation, an inverse direction transformation, or another inverse transformation to the transformation coefficient block.

[0195]

[0169] Furthermore, the prediction processing unit 304 generates prediction blocks according to the prediction information syntax elements entropy-decoded by the entropy decoding unit 302. For example, if the prediction information syntax elements indicate that the current block is interpredicted, the motion compensation unit 316 may generate prediction blocks. In this case, the prediction information syntax elements may indicate a reference picture in the DPB 314 from which the reference block should be extracted, as well as a motion vector that identifies the location of the reference block in the reference picture relative to the location of the current block in the current picture. The motion compensation unit 316 may generally perform the interprediction process in a manner substantially similar to that described with respect to the motion compensation unit 224 (Figure 5).

[0196]

[0170] As another example, if the prediction information syntax element indicates that the current block is intra-predicted, the intra-prediction unit 318 may generate a predicted block according to the intra-prediction mode indicated by the prediction information syntax element. In this case as well, the intra-prediction unit 318 may carry out the intra-prediction process in a manner that is generally substantially the same as that described with respect to the intra-prediction unit 226 (Figure 5). The intra-prediction unit 318 may retrieve adjacent sample data for the current block from the DPB 314.

[0197]

[0171] The reconstruction unit 310 may reconstruct the current block using the predicted block and the residual block. For example, the reconstruction unit 310 may add the samples of the residual block to the corresponding samples of the predicted block in order to reconstruct the current block.

[0198]

[0172] The filter unit 312 may perform one or more filtering operations on the reconstructed block. For example, the filter unit 312 may perform a deblocking operation to reduce blocking artifacts along the edges of the reconstructed block. The operations of the filter unit 312 are not necessarily performed in all examples.

[0199]

[0173] The video decoder 300 may store the reconstructed blocks in the DPB 314. For example, in an example where the filter unit 312 does not operate, the reconstruction unit 310 may store the reconstructed blocks in the DPB 314. In an example where the filter unit 312 operates, the filter unit 312 may store the filtered reconstructed blocks in the DPB 314. As described above, the DPB 314 may provide the prediction processing unit 304 with reference information, such as a sample of the current picture for intra-prediction and a previously decoded picture for subsequent motion compensation. Furthermore, the video decoder 300 may output the decoded picture from the DPB 314 (e.g., decoded video) for subsequent presentation on a display device such as the display device 118 in Figure 1.

[0200]

[0174] Thus the video decoder 300 represents an example of a device for decoding video data, the device comprising a memory configured to store video data and one or more processors implemented in the circuit, the one or more processors configured to calculate the sum of the absolute values ​​of a plurality of adjacent coefficients for the current coefficient for the current block of video data, calculate a base-level offset value according to at least one of the bit depth for the video data or the slice type for the slice containing the current block, calculate a normalized value for the sum of absolute values ​​using the base-level offset value, and code the current coefficient using the normalized value for the sum of absolute values.

[0201]

[0175] Figure 7 is a flowchart illustrating an exemplary method for encoding a current block using the technique of the present disclosure. A current block may comprise a current CU. While the video encoder 200 (Figures 1 and 5) is described, it should be understood that other devices may be configured to perform a similar method to that of Figure 7.

[0202]

[0176] In this example, the video encoder 200 first predicts the current block (350). For example, the video encoder 200 may form a predicted block for the current block. The video encoder 200 may then compute the residual block for the current block (352). To compute the residual block, the video encoder 200 may compute the difference between the original uncoded block and the predicted block for the current block. The video encoder 200 may then transform the residual block and quantize the transformation coefficients of the residual block (354). The video encoder 200 may then scan the quantized transformation coefficients of the residual block (356). During or following the scan, the video encoder 200 may entropy encode the transformation coefficients (358). For example, the video encoder 200 may encode the transformation coefficients using CAVLC or CABAC. When the video encoder 200 entropy encodes the transformation coefficients, it may apply any or all of the Rice parameter derivation techniques described herein. The video encoder 200 may then output the entropy-encoded data of the block (360).

[0203]

[0177] The video encoder 200 may also decode the current block after encoding it in order to use the decoded version of the current block as reference data for data to be coded later (for example, in inter-prediction mode or intra-prediction mode). Thus, the video encoder 200 may inversely quantize the coefficients and inversely transform them to reconstruct the residual block (362). The video encoder 200 may combine the residual block with the prediction block to form the decoded block (364). The video encoder 200 may then store the decoded block in the DPB 218 (366).

[0204]

[0178] Figure 8 is a flowchart illustrating an exemplary method for decoding a current block of video data using the technique of the present disclosure. The current block may comprise a current CU. While the video decoder 300 (Figures 1 and 6) is described, it should be understood that other devices may be configured to perform a similar method to that of Figure 8.

[0205]

[0179] The video decoder 300 may receive entropy-encoded data about the current block, such as entropy-encoded prediction information and entropy-encoded data about the transformation coefficients of the residual block corresponding to the current block (370). The video decoder 300 may entropy-decode the entropy-encoded data to determine the prediction information for the current block and to reconstruct the transformation coefficients of the residual block (372). When entropy-decoding the transformation coefficients, the video decoder 300 may apply any or all of the Rice parameter derivation techniques described herein.

[0206]

[0180] The video decoder 300 may predict the current block, for example, using an intra-prediction or inter-prediction mode indicated by the prediction information for the current block, in order to compute a predicted block for the current block (374). The video decoder 300 may then reverse scan the reconstructed transformation coefficients to create a block of quantized transformation coefficients (376). The video decoder 300 may then inverse quantize the transformation coefficients and apply an inverse transformation to the transformation coefficients to produce a residual block (378). The video decoder 300 may finally decode the current block by combining the predicted block and the residual block (380).

[0207]

[0181] Figure 9 is a flowchart illustrating an exemplary method for encoding video data using the technique of the present disclosure. The method of Figure 9 may generally correspond to step 358 of Figure 7.

[0208]

[0182] First, the video encoder 200 may determine the current coefficient value of the current block of video data (400). The video encoder 200 may divide the current coefficient value into values ​​for each syntax element, such as the significance coefficient syntax element, the syntax element greater than 1, the syntax element greater than 2, the residual syntax element, and the sign syntax element. The method in Figure 9 illustrates the encoding of the value of the residual syntax element. However, other syntax elements, such as the dec_abs_level[] syntax element, may be encoded using this method or a similar method.

[0209]

[0183] The video encoder 200 may then calculate the value of the local sum of absolute values ​​(402). For example, the video encoder 200 may determine the absolute value of the values ​​of the coefficients adjacent to the current coefficient. In the example of Figure 2, for example, adjacent coefficients may include the adjacent coefficient to the right, the adjacent coefficient two positions to the right, the adjacent coefficient to the lower right, the adjacent coefficient below, and the adjacent coefficient two positions below. The video encoder 200 may add the sum of the absolute values ​​of the adjacent coefficients as the value of the local sum of absolute values.

[0210]

[0184] The video encoder 200 may then calculate a base level offset value according to the bit depth and / or slice type for the slice containing the current block (404). For example, the video encoder 200 may calculate a base level offset value (baseLevelOffset) according to the following:

[0211]

number

[0212] Therefore, the video encoder 200 can determine whether the bit depth of the video data is greater than a threshold T. If the bit depth is greater than the threshold, the video encoder 200 can determine whether the slice type is intra-predictive. If the slice type is intra-predictive, the video encoder 200 can determine that the base-level offset value is P1. If the slice type is not intra-predictive (e.g., inter-predictive, such as a P-slice or B-slice), the video encoder 200 can determine that the base-level offset value is P2. If the bit depth is less than or equal to the threshold, the video encoder 200 can also determine whether the slice type is intra-predictive. If the slice type is intra-predictive, the video encoder 200 can determine that the base-level offset value is P3. If the slice type is not intra-predictive (e.g., inter-predictive, such as a P-slice or B-slice), the video encoder 200 can determine that the base-level offset value is P4. P1, P2, P3, and P4 may be predefined values, or the video encoder 200 may determine the values ​​for P1, P2, P3, and P4 and signal the determined values ​​in the bitstream.

[0213]

[0185] The video encoder 200 may then normalize the local sum of absolute values ​​using the calculated base-level offset value (406). For example, the video encoder 200 may calculate the following:

[0214]

number

[0215] In this example, locSumAbs (local sum of absolute values) is updated using the clipping operation Clip3, for example, according to VVC, and using the calculated baseLevelOffset value.

[0216]

[0186] The video encoder 200 may then determine the Rice parameters from the normalized values ​​(408). For example, the video encoder 200 may use Table 1 as a lookup table to determine the Rice parameters.

[0217]

[0187] The video encoder 200 may then use the Rice parameter to determine a Golomb-Rice code for a coefficient value (e.g., a residual value) (410). The Golomb-Rice code may be a series of bits (bins). The video encoder 200 may then entropy encode the Golomb-Rice code (412).

[0218]

[0188] Thus, the method in Figure 9 represents an example of a method for encoding video data, the method comprising: calculating the sum of the absolute values ​​of a number of coefficients adjacent to the current coefficient for the current block of video data; calculating a base-level offset value according to at least one of the bit depth for the video data or the slice type for the slice containing the current block; calculating a normalized value for the sum of absolute values ​​using the base-level offset value; and coding the current coefficient using the normalized value for the sum of absolute values.

[0219]

[0189] Figure 10 is a flowchart illustrating an exemplary method for decoding video data using the technique of the present disclosure. The method in Figure 10 may generally correspond to step 372 of Figure 8.

[0220]

[0190] First, the video decoder 300 can entropy decode the Golomb-Rice code for the current coefficients of the current block of video data (420). The Golomb-Rice code may correspond to the residual values ​​of the current coefficients, which may further include significance coefficient syntax elements, syntax elements greater than 1, syntax elements greater than 2, and sign syntax elements. The example in Figure 10 deals with decoding the residual values ​​for the current coefficients, but the method in Figure 10 can also be used to decode other values, such as values ​​for the dec_abs_level[] syntax elements.

[0221]

[0191] The video decoder 300 can then calculate the value of the local sum of absolute values ​​(422). For example, the video decoder 300 can determine the absolute value of the adjacent coefficients with respect to the current coefficient. With respect to the example in Figure 2, for example, adjacent coefficients may include the adjacent coefficient to the right, the adjacent coefficient two positions to the right, the adjacent coefficient to the lower right, the adjacent coefficient below, and the adjacent coefficient two positions below. The video decoder 300 can add the sum of the absolute values ​​of the adjacent coefficients as the value of the local sum of absolute values.

[0222]

[0192] The video decoder 300 may then calculate a base level offset value according to the bit depth and / or slice type for the slice containing the current block (424). For example, the video decoder 300 may calculate a base level offset value (baseLevelOffset) according to the following:

[0223]

number

[0224] Therefore, the video decoder 300 can determine whether the bit depth of the video data is greater than a threshold T. If the bit depth is greater than the threshold, the video decoder 300 can determine whether the slice type is intra-predictive. If the slice type is intra-predictive, the video decoder 300 can determine that the base-level offset value is P1. If the slice type is not intra-predictive (e.g., inter-predictive, such as a P-slice or B-slice), the video decoder 300 can determine that the base-level offset value is P2. If the bit depth is less than or equal to the threshold, the video decoder 300 can also determine whether the slice type is intra-predictive. If the slice type is intra-predictive, the video decoder 300 can determine that the base-level offset value is P3. If the slice type is not intra-predictive (e.g., inter-predictive, such as a P-slice or B-slice), the video decoder 300 can determine that the base-level offset value is P4. P1, P2, P3, and P4 may be predefined values, or the video decoder 300 may decode values ​​for P1, P2, P3, and P4 from the bitstream.

[0225]

[0193] The video decoder 300 may then normalize the local sum of absolute values ​​using the calculated base-level offset value (426). For example, the video decoder 300 may calculate the following:

[0226]

number

[0227] In this example, locSumAbs (local sum of absolute values) is updated using the clipping operation Clip3, for example, according to VVC, and using the calculated baseLevelOffset value.

[0228]

[0194] The video decoder 300 may then determine the Rice parameters from the normalized values ​​(428). For example, the video decoder 300 may determine the Rice parameters using Table 1 as a lookup table.

[0229]

[0195] The video decoder 300 may then use the Rice parameters to form a binarized (binary) value representing the residual value from the Golomb Rice code (430). The video decoder 300 may further reconstruct the coefficient value from the binarized value (432). For example, the video decoder 300 may concatenate the value for the significance coefficient syntax element, the value for the syntax element greater than 1, the value for the syntax element greater than 2, and the value for the residual value.

[0230]

[0196] Thus, the method in Figure 9 represents an example of a method for decoding video data, the method comprising: calculating the sum of the absolute values ​​of several adjacent coefficients for the current coefficient for the current block of video data; calculating a base-level offset value according to at least one of the bit depth for the video data or the slice type for the slice containing the current block; calculating a normalized value for the sum of absolute values ​​using the base-level offset value; and coding the current coefficient using the normalized value for the sum of absolute values.

[0231]

[0197] Some examples of the various techniques of this disclosure are summarized in the following clauses.

[0232]

[0198] Clause 1: A method for coding video data, the method comprising: calculating the sum of the absolute values ​​of a plurality of adjacent coefficients for a current coefficient for a current block of video data; calculating a base-level offset value according to at least one of a bit depth for video data or a slice type for a slice containing the current block; calculating a normalized value for the sum of absolute values ​​using the base-level offset value; and coding the current coefficient using the normalized value for the sum of absolute values.

[0233]

[0199] Clause 2: The method according to Clause 1, wherein multiple adjacent coefficients include five adjacent coefficients with respect to the current coefficient.

[0234]

[0200] Clause 3: The method according to either of Clauses 1 or 2, wherein the number of adjacent coefficients includes two adjacent coefficients to the right of the current coefficient, two adjacent coefficients below the current coefficient, and one adjacent coefficient to the left of the current coefficient.

[0235]

[0201] Clause 4: The method according to any one of Clauses 1 to 3, wherein calculating the base level offset value comprises calculating baseLevelOffset=(bitDepth>T)?(isIntra()?P1:P2):(isIntra()?P3:P4), where bitDepth comprises the bit depth for the video data, isIntra() returns a true value if the slice type for the slice is an intra-predicted slice, or a false value if the slice type for the slice is an inter-predicted slice, and T, P1, P2, P3, and P4 comprises their respective input values.

[0236]

[0202] Clause 5: The method according to Clause 4, wherein the input values ​​for T, P1, P2, P3, and P4 are predetermined.

[0237]

[0203] Clause 6: The method according to Clause 4, wherein input values ​​for T, P1, P2, P3, and P4 are signaled in the bitstream.

[0238]

[0204] Clause 7: The method according to any of Clauses 4 to 6, where T=12, P1=5, P2=10, P3=6, P4=20.

[0239]

[0205] Clause 8: The method according to any of Clauses 4 to 6, where T=12, P1=5, P2=10, P3=10, P4=20.

[0240]

[0206] Clause 9: The method of any one of Clauses 1 to 8, wherein calculating a normalized value for the sum of absolute values ​​comprises calculating Clip3(0,31,locSumAbs-baseLevelOffset), where locSumAbs comprises the sum of absolute values ​​and baseLevelOffset comprises the base-level offset value.

[0241]

[0207] Clause 10: A method for coding video data, the method comprising: maintaining a history counter representing a history of Rice parameters used to code the coefficients of the color components of the video data; deriving a Rice parameter scaling value for a block of color components of the video data from a current value of the history counter without explicitly coding a value for the Rice parameter scaling value; calculating the sum of the absolute values ​​of a number of adjacent coefficients for the current coefficient of the block; calculating a scaled value for the sum of absolute values ​​using the Rice parameter scaling value; and coding the current coefficient using the scaled value for the sum of absolute values.

[0242]

[0208] Clause 11: A method comprising a combination of the method described in any of Clauses 1 to 9 and the method described in Clause 10.

[0243] Clause 12: Deriving a Rice parameter scaling value comprises calculating (StatCoeff[idx]≧T)?P2:P1, where idx represents a color component, StatCoeff[idx] represents the current value for a history counter, and T, P1, and P2 represent input values, according to the method described in either of Clauses 10 and 11.

[0244] Clause 13: The method according to Clause 12, wherein input values for T, P1, and P2 are determined in advance.

[0245] Clause 14: The method according to Clause 12, wherein input values for T, P1, and P2 are signaled in the video data.

[0246] Clause 15: The method according to any of Clauses 12 to 14, wherein T = 4, P2 = 2, and P1 = 1.

[0247] Clause 16: Deriving a Rice parameter scaling value comprises calculating an aggregated history counter value representing an aggregation of history counters including the history counter for all color components including the color components of the video data, and deriving the Rice parameter scaling value using the aggregated history counter value, according to the method described in either of Clauses 10 and 11.

[0248]

[0214] Clause 17: The method according to Clause 16, comprising calculating the aggregated history counter value by calculating ((StatCoeff[0]*w0)+StatCoeff[1]*w1+StatCoeff[2]*w2) / (w1+w2+w3), where StatCoeff[0] represents the first history counter of the history counters for the first color component of the color components, StatCoeff[1] represents the second history counter of the history counters for the second color component of the color components, StatCoeff[2] represents the third history counter of the history counters for the third color component of the color components, and w1, w2, and w3 represent their respective weighted values.

[0249]

[0215] Clause 18: The method of Clause 17, wherein the deriving of a rice parameter scaling value is the method of deriving a rice parameter scaling value using (StatCoefAverage≧T)?P2:P1, where StatCoefAverage represents the aggregated historical counter value and T, P1, and P2 represent input values.

[0250]

[0216] Clause 19: The method according to Clause 18, wherein the input values ​​for T, P1, and P2 are predetermined.

[0251]

[0217] Clause 20: The method according to Clause 18, wherein input values ​​for T, P1, and P2 are signaled in the video data.

[0252]

[0218] Clause 21: The method according to any one of Clauses 18 to 20, wherein T=4, P2=2 and P1=1.

[0253]

[0219] Clause 22: The method according to any of Clauses 18 to 21, wherein w0=2, w1=1, and w2=1.

[0254]

[0220] Clause 23: The method according to any one of Clauses 10 to 22, wherein the block comprises a coding tree unit (CTU).

[0255]

[0221] Clause 24: The method according to any one of Clauses 10 to 22, wherein the block comprises a conversion unit (TU).

[0256]

[0222] Clause 25: The method according to any one of Clauses 10 to 22, wherein the block comprises a subconversion unit (subTU).

[0257]

[0223] Clause 26: The method according to any one of Clauses 10 to 22, wherein the block comprises a first block and the rice parameter scaling value comprises a first rice parameter scaling value, and the method further comprises deriving a second rice parameter scaling value for a second block using the first rice parameter scaling value.

[0258]

[0224] Clause 27: A method for coding video data, the method comprising: calculating the sum of the absolute values ​​of a plurality of adjacent coefficients for a current coefficient for a current block of video data; calculating a base-level offset value according to at least one of a bit depth for video data or a slice type for a slice containing the current block; calculating a normalized value for the sum of absolute values ​​using the base-level offset value; and coding the current coefficient using the normalized value for the sum of absolute values.

[0259]

[0225] Clause 28: The method according to Clause 27, wherein the multiple adjacent coefficients include five adjacent coefficients with respect to the current coefficient.

[0260]

[0226] Clause 29: The method according to Clause 27, wherein the number of adjacent coefficients includes two adjacent coefficients to the right of the current coefficient, two adjacent coefficients below the current coefficient, and one adjacent coefficient to the left of the current coefficient.

[0261]

[0227] Clause 30: The method of Clause 27, wherein calculating the base level offset value comprises calculating baseLevelOffset=(bitDepth>T)?(isIntra()?P1:P2):(isIntra()?P3:P4), where bitDepth comprises the bit depth for the video data, isIntra() returns a true value if the slice type for the slice is an intra-predicted slice, or a false value if the slice type for the slice is an inter-predicted slice, and T, P1, P2, P3, and P4 comprises their respective input values.

[0262]

[0228] Clause 31: The method according to Clause 30, wherein the input values ​​for T, P1, P2, P3, and P4 are predetermined.

[0263]

[0229] Clause 32: The method according to Clause 30, wherein input values ​​for T, P1, P2, P3, and P4 are signaled in the bitstream.

[0264]

[0230] Clause 33: The method according to Clause 30, where T=12, P1=5, P2=10, P3=6, P4=20.

[0265]

[0231] Clause 34: The method according to Clause 30, where T=12, P1=5, P2=10, P3=10, P4=20.

[0266]

[0232] Clause 35: The method of Clause 27, wherein calculating a normalized value for the sum of absolute values ​​comprises calculating Clip3(0,31,locSumAbs-baseLevelOffset), where locSumAbs is the sum of absolute values ​​and baseLevelOffset is the base-level offset value.

[0267]

[0233] Clause 36: A method for coding video data, the method comprising: maintaining a history counter representing a history of Rice parameters used to code coefficients of color components of the video data; deriving a Rice parameter scaling value for a block of color components of the video data from a current value of the history counter without explicitly coding a value for the Rice parameter scaling value; calculating a sum of absolute values of a plurality of adjacent coefficients with respect to a current coefficient of the block; calculating a scaled value for the sum of absolute values using the Rice parameter scaling value; and coding the current coefficient using the scaled value for the sum of absolute values.

[0268]

[0234] Clause 37: The method according to clause 36, wherein deriving the Rice parameter scaling value comprises calculating (StatCoeff[idx]≧T)?P2:P1, where idx represents a color component, StatCoeff[idx] represents a current value of the history counter, and T, P1, and P2 represent input values.

[0269]

[0235] Clause 38: The method according to clause 37, wherein input values for T, P1, and P2 are determined in advance.

[0270]

[0236] Clause 39: The method according to clause 37, wherein input values for T, P1, and P2 are signaled in the video data.

[0271]

[0237] Clause 40: The method according to clause 37, wherein T = 4, P2 = 2, and P1 = 1.

[0272]

[0238] Clause 41: The method of Clause 36, wherein deriving a rice parameter scaling value comprises calculating an aggregated history counter value representing an aggregation of history counters, including history counters for all color components, including color components of video data, and deriving a rice parameter scaling value using the aggregated history counter value.

[0273]

[0239] Clause 42: The method according to Clause 41, comprising calculating the aggregated history counter value by calculating ((StatCoeff[0]*w0)+StatCoeff[1]*w1+StatCoeff[2]*w2) / (w1+w2+w3), where StatCoeff[0] represents the first history counter of the history counters for the first color component of the color components, StatCoeff[1] represents the second history counter of the history counters for the second color component of the color components, StatCoeff[2] represents the third history counter of the history counters for the third color component of the color components, and w1, w2, and w3 represent their respective weighted values.

[0274]

[0240] Clause 43: The method of Clause 42, wherein the deriving of the rice parameter scaling value is to derive the rice parameter scaling value using (StatCoefAverage≧T)?P2:P1, where StatCoefAverage represents the aggregated historical counter value and T, P1, and P2 represent the input values.

[0275]

[0241] Clause 44: The method according to Clause 43, wherein the input values ​​for T, P1, and P2 are predetermined.

[0276]

[0242] Clause 45: The method according to Clause 43, wherein input values ​​for T, P1, and P2 are signaled in the video data.

[0277]

[0243] Clause 46: The method according to Clause 43, wherein T=4, P2=2 and P1=1.

[0278]

[0244] Clause 47: The method according to Clause 43, where w0=2, w1=1, and w2=1.

[0279]

[0245] Clause 48: The method according to Clause 36, wherein the block comprises a coding tree unit (CTU).

[0280]

[0246] Clause 49: The method according to Clause 36, wherein the block comprises a conversion unit (TU).

[0281]

[0247] Clause 50: The method according to Clause 36, wherein the block comprises a subconversion unit (subTU).

[0282]

[0248] Clause 51: The method of Clause 36, wherein a block comprises a first block and a rice parameter scaling value comprises a first rice parameter scaling value, and the method further comprises deriving a second rice parameter scaling value for a second block using the first rice parameter scaling value.

[0283]

[0249] Clause 52: The method of any one of Clauses 1 to 51, comprising coding and decoding.

[0284]

[0250] Clause 53: The method of any one of Clauses 1 to 52, wherein coding comprises encoding.

[0285]

[0251] Clause 54: A device for coding video data, wherein the device comprises one or more means for carrying out the method described in any of Clauses 1 to 53.

[0286]

[0252] Clause 55: The device according to Clause 54, wherein one or more means comprises one or more processors implemented in the circuit.

[0287]

[0253] Clause 56: The device according to any one of Clauses 54 to 55, further comprising a display configured to display decoded video data.

[0288]

[0254] Clause 57: A device as described in any of Clauses 54 to 56, comprising one or more of a camera, computer, mobile device, broadcast receiver device, or set-top box.

[0289]

[0255] Clause 58: The device described in any of Clauses 54 to 57, further comprising memory configured to store video data.

[0290]

[0256] Clause 59: A computer-readable storage medium storing instructions, wherein, when the instructions are executed, the instructions cause a processor of a device for decoding video data to perform the method described in any of Clauses 1 to 53.

[0291]

[0257] Clause 60: A device for coding video data, the device comprising means for calculating the sum of the absolute values ​​of a plurality of adjacent coefficients for a current coefficient for a current block of video data; means for calculating a base-level offset value according to at least one of a bit depth for video data or a slice type for a slice containing the current block; means for calculating a normalized value for the sum of absolute values ​​using the base-level offset value; and means for coding the current coefficient using the normalized value for the sum of absolute values.

[0292]

[0258] Clause 61: A device for coding video data, the device comprising: means for maintaining a history counter representing a history of Rice parameters used to code the coefficients of the color components of video data; means for deriving a Rice parameter scaling value for a block of color components of video data from a current value of the history counter without explicitly coding a value for the Rice parameter scaling value; means for calculating the sum of the absolute values ​​of a plurality of adjacent coefficients with respect to the current coefficient of the block; means for calculating a scaled value for the sum of absolute values ​​using the Rice parameter scaling value; and means for coding the current coefficient using the scaled value for the sum of absolute values.

[0293]

[0259] Clause 62: A method for coding video data, the method comprising: calculating the sum of the absolute values ​​of a plurality of adjacent coefficients for a current coefficient for a current block of video data; calculating a base-level offset value according to at least one of a bit depth for video data or a slice type for a slice containing the current block; calculating a normalized value for the sum of absolute values ​​using the base-level offset value; and coding the current coefficient using the normalized value for the sum of absolute values.

[0294]

[0260] Clause 63: The method according to Clause 62, wherein the multiple adjacent coefficients include five adjacent coefficients with respect to the current coefficient.

[0295]

[0261] Clause 64: The method according to Clause 62, wherein the number of adjacent coefficients includes two adjacent coefficients to the right of the current coefficient, two adjacent coefficients below the current coefficient, and one adjacent coefficient to the left of the current coefficient.

[0296]

[0262] Clause 65: The method of Clause 62, wherein calculating the base level offset value comprises calculating baseLevelOffset=(bitDepth>T)?(isIntra()?P1:P2):(isIntra()?P3:P4), where bitDepth comprises the bit depth for the video data, isIntra() returns a true value if the slice type for the slice is an intra-predicted slice, or a false value if the slice type for the slice is an inter-predicted slice, and T, P1, P2, P3, and P4 comprises their respective input values.

[0297]

[0263] Clause 66: The method described in Clause 65, wherein T=12.

[0298]

[0264] Clause 67: The method according to Clause 66, wherein P1=5, P2=10, P3=6, and P4=20.

[0299]

[0265] Clause 68: The method according to Clause 66, wherein P1=5, P2=10, P3=10, and P4=20.

[0300]

[0266] Clause 69: The method according to Clause 65, wherein the input values ​​for T, P1, P2, P3, and P4 are predetermined.

[0301]

[0267] Clause 70: The method according to Clause 65, wherein input values ​​for T, P1, P2, P3, and P4 are signaled in the bitstream.

[0302]

[0268] Clause 71: The method of Clause 62, wherein calculating a normalized value for the sum of absolute values ​​comprises calculating Clip3(0,31,locSumAbs-baseLevelOffset), where locSumAbs is the sum of absolute values ​​and baseLevelOffset is the base-level offset value.

[0303]

[0269] Clause 72: The method of Clause 62, comprising coding the current coefficients using a normalized value for the sum of absolute values, determining the Rice parameter corresponding to the normalized value for the sum of absolute values, and binarizing the value for the current coefficients using the Rice parameter to form a binarized value.

[0304]

[0270] Clause 73: The method according to Clause 62, wherein the current block comprises a first block, the color components of video data comprises a first block, the sum of absolute values ​​comprises a first sum of absolute values, and a plurality of adjacent coefficients comprises a first plurality of adjacent coefficients, and the method further comprises: maintaining a history counter representing the history of the Rice parameters used to code the coefficients of the color components of video data; deriving a Rice parameter scaling value for a second block of the color components of video data from the current value of the history counter without explicitly coding a value for the Rice parameter scaling value; calculating a second sum of absolute values ​​of the second plurality of adjacent coefficients for a second coefficient of the second block; calculating a scaled value for the second sum of absolute values ​​using the Rice parameter scaling value; and coding the second coefficient of the second block using the scaled value for the second sum of absolute values.

[0305]

[0271] Clause 74: The method according to Clause 12, wherein deriving the Rice parameter scaling value comprises calculating (StatCoeff[idx]≧T)?P2:P1, where idx represents the color component, StatCoeff[idx] represents the current value for the history counter, and T, P1, and P2 represent the input values.

[0306]

[0272] Clause 75: The method according to Clause 13, wherein the input values ​​for T, P1, and P2 are predetermined.

[0307]

[0273] Clause 76: The method according to Clause 13, wherein input values ​​for T, P1, and P2 are signaled in the video data.

[0308]

[0274] Clause 77: The method according to Clause 13, wherein T=4, P2=2 and P1=1.

[0309]

[0275] Clause 78: The method of Clause 12, wherein deriving a rice parameter scaling value comprises calculating an aggregated history counter value representing an aggregation of history counters, including history counters for all color components, including color components of video data, and deriving a rice parameter scaling value using the aggregated history counter value.

[0310]

[0276] Clause 79: The method according to Clause 17, comprising calculating the aggregated history counter value by calculating ((StatCoeff[0]*w0)+StatCoeff[1]*w1+StatCoeff[2]*w2) / (w1+w2+w3), where StatCoeff[0] represents the first history counter of the history counters for the first color component of the color components, StatCoeff[1] represents the second history counter of the history counters for the second color component of the color components, StatCoeff[2] represents the third history counter of the history counters for the third color component of the color components, and w1, w2, and w3 represent their respective weighted values.

[0311]

[0277] Clause 80: The method of Clause 18, wherein the deriving of a rice parameter scaling value is the method of deriving a rice parameter scaling value using (StatCoefAverage≧T)?P2:P1, where StatCoefAverage represents an aggregated historical counter value and T, P1, and P2 represent input values.

[0312]

[0278] Clause 81: The method according to Clause 19, wherein the input values ​​for T, P1, and P2 are predetermined.

[0313]

[0279] Clause 82: The method according to Clause 19, wherein input values ​​for T, P1, and P2 are signaled in the video data.

[0314]

[0280] Clause 83: The method according to Clause 19, wherein T=4, P2=2 and P1=1.

[0315]

[0281] Clause 84: The method according to Clause 19, where w0=2, w1=1, and w2=1.

[0316]

[0282] Clause 85: The method according to Clause 12, wherein the second block comprises one of a coding tree unit (CTU), a translation unit (TU), or a sub-translation unit (sub-TU).

[0317]

[0283] Clause 86: The method according to Clause 62, wherein one or more processors are configured to decode the current coefficients using normalized values ​​of the sum of absolute values ​​in order to code the current coefficients.

[0318]

[0284] Clause 87: The method according to Clause 62, wherein one or more processors are configured to encode the current coefficients using normalized values ​​of the sum of absolute values ​​in order to encode the current coefficients.

[0319]

[0285] Clause 88: A device for coding video data, the device comprising a memory configured to store video data and one or more processors implemented in the circuit, wherein one or more processors are configured to calculate the sum of the absolute values ​​of a plurality of adjacent coefficients for a current coefficient for a current block of video data; calculate a base-level offset value according to at least one of the bit depth for video data or a slice type for a slice containing the current block; calculate a normalized value for the sum of absolute values ​​using the base-level offset value; and code the current coefficient using the normalized value for the sum of absolute values.

[0320]

[0286] Clause 89: The device according to Clause 27, wherein multiple adjacent coefficients include five adjacent coefficients relative to the current coefficient.

[0321]

[0287] Clause 90: The device according to Clause 27, wherein the number of adjacent coefficients includes two adjacent coefficients to the right of the current coefficient, two adjacent coefficients below the current coefficient, and one adjacent coefficient to the left of the current coefficient.

[0322]

[0288] Clause 91: The device described in Clause 27, wherein one or more processors are configured to compute baseLevelOffset=(bitDepth>T)?(isIntra()?P1:P2):(isIntra()?P3:P4) for calculating a baselevel offset value, where bitDepth is the bit depth for the video data, isIntra() returns a true value if the slice type for the slice is an intra-predicted slice, or a false value if the slice type for the slice is an inter-predicted slice, and T, P1, P2, P3, and P4 are their respective input values.

[0323]

[0289] Clause 92: The device described in Clause 30, where T=12.

[0324]

[0290] Clause 93: The device described in Clause 30, wherein the input values ​​for T, P1, P2, P3, and P4 are predetermined.

[0325]

[0291] Clause 94: The device according to Clause 27, wherein one or more processors are configured to compute Clip3(0,31,locSumAbs-baseLevelOffset) for the purpose of computing a normalized value for the sum of absolute values, where locSumAbs comprises the sum of absolute values ​​and baseLevelOffset comprises the base-level offset value.

[0326]

[0292] Clause 95: The device according to Clause 27, wherein one or more processors are configured to determine a rice parameter corresponding to a normalized value for the sum of absolute values ​​and to binarize the value for the current coefficient using the rice parameter in order to code the current coefficient using a normalized value for the sum of absolute values.

[0327]

[0293] Clause 96: The device according to Clause 27, wherein the current block comprises a first block, the color components of video data comprises a first sum of absolute values, and a plurality of adjacent coefficients comprises a first plurality of adjacent coefficients, wherein one or more processors are further configured to maintain a history counter representing a history of Rice parameters used to code the coefficients of the color components of video data; derive a Rice parameter scaling value for a second block of the color components of video data from the current value of the history counter without explicitly coding a value for the Rice parameter scaling value; calculate a second sum of absolute values ​​of the second plurality of adjacent coefficients for a second coefficient of the second block; calculate a scaled value for the second sum of absolute values ​​using the Rice parameter scaling value; and code the second coefficient of the second block using the scaled value for the second sum of absolute values.

[0328]

[0294] Clause 97: The device according to Clause 35, wherein one or more processors are configured to calculate (StatCoeff[idx]≧T)?P2:P1 in order to derive a Rice parameter scaling value, where idx represents a color component, StatCoeff[idx] represents the current value for a history counter, and T, P1, and P2 represent input values.

[0329]

[0295] Clause 98: The device according to Clause 27, wherein one or more processors are configured to encode the current coefficients using normalized values ​​of the sum of absolute values, or to decode the current coefficients using normalized values ​​of the sum of absolute values.

[0330]

[0296] Clause 99: The device described in Clause 27, further comprising a display configured to display decoded video data.

[0331]

[0297] Clause 100: A device as described in Clause 27, comprising one or more of the following: a camera, a computer, a mobile device, a broadcast receiver device, or a set-top box.

[0332]

[0298] Clause 101: A computer-readable storage medium storing instructions, wherein, when the instructions are executed, the instructions cause a processor of a device for coding video data to calculate the sum of the absolute values ​​of a plurality of adjacent coefficients for a current coefficient for a current block of video data; calculate a base-level offset value according to at least one of the bit depth for video data or the slice type for a slice containing the current block; calculate a normalized value for the sum of absolute values ​​using the base-level offset value; and code the current coefficient using the normalized value for the sum of absolute values.

[0333]

[0299] Clause 102: A device for coding video data, the device comprising: means for calculating the sum of the absolute values ​​of a plurality of adjacent coefficients for a current coefficient for a current block of video data; means for calculating a base-level offset value according to at least one of a bit depth for video data or a slice type for a slice containing the current block; means for calculating a normalized value for the sum of absolute values ​​using the base-level offset value; and means for coding the current coefficient using the normalized value for the sum of absolute values.

[0334]

[0300] Clause 103: A method for coding video data, the method comprising: calculating the sum of the absolute values ​​of a plurality of adjacent coefficients for a current coefficient for a current block of video data; calculating a base-level offset value according to at least one of a bit depth for video data or a slice type for a slice containing the current block; calculating a normalized value for the sum of absolute values ​​using the base-level offset value; and coding the current coefficient using the normalized value for the sum of absolute values.

[0335]

[0301] Clause 104: The method according to Clause 103, wherein multiple adjacent coefficients include five adjacent coefficients with respect to the current coefficient.

[0336]

[0302] Clause 105: The method according to either of Clauses 103 and 104, wherein the number of adjacent coefficients includes two adjacent coefficients to the right of the current coefficient, two adjacent coefficients below the current coefficient, and one adjacent coefficient to the left of the current coefficient.

[0337]

[0303] Clause 106: The method according to any one of Clauses 103 to 105, wherein calculating the base level offset value comprises calculating baseLevelOffset=(bitDepth>T)?(isIntra()?P1:P2):(isIntra()?P3:P4), where bitDepth comprises the bit depth for the video data, isIntra() returns a true value if the slice type for the slice is an intra-predicted slice, or a false value if the slice type for the slice is an inter-predicted slice, and T, P1, P2, P3, and P4 comprises their respective input values.

[0338]

[0304] Clause 107: The method according to Clause 106, wherein T=12.

[0339]

[0305] Clause 108: The method according to Clause 107, wherein P1=5, P2=10, P3=6, and P4=20.

[0340]

[0306] Clause 109: The method according to Clause 107, wherein P1=5, P2=10, P3=10, and P4=20.

[0341]

[0307] Clause 110: The method according to any of Clauses 106 to 109, wherein the input values ​​for T, P1, P2, P3, and P4 are predetermined.

[0342]

[0308] Clause 111: The method according to any of Clauses 106 to 109, wherein input values ​​for T, P1, P2, P3, and P4 are signaled in the bitstream.

[0343]

[0309] Clause 112: The method according to any one of Clauses 103 to 111, wherein calculating a normalized value for the sum of absolute values ​​comprises calculating Clip3(0,31,locSumAbs-baseLevelOffset), where locSumAbs comprises the sum of absolute values ​​and baseLevelOffset comprises the base-level offset value.

[0344]

[0310] Clause 113: The method according to any one of Clauses 103 to 112, wherein coding the current coefficients using normalized values ​​for the sum of absolute values ​​comprises determining the Rice parameter corresponding to the normalized values ​​for the sum of absolute values, and binarizing the values ​​for the current coefficients using the Rice parameter to form binarized values.

[0345]

[0311] Clause 114: The method of any one of Clauses 103 to 113, wherein the current block comprises a first block, the color components of video data comprises a first sum of absolute values, and a plurality of adjacent coefficients comprises a first plurality of adjacent coefficients, and the method further comprises: maintaining a history counter representing the history of the Rice parameters used to code the coefficients of the color components of video data; deriving a Rice parameter scaling value for a second block of the color components of video data from the current value of the history counter without explicitly coding a value for the Rice parameter scaling value; calculating a second sum of absolute values ​​of the second plurality of adjacent coefficients for a second coefficient of the second block; calculating a scaled value for the second sum of absolute values ​​using the Rice parameter scaling value; and coding the second coefficient of the second block using the scaled value for the second sum of absolute values.

[0346]

[0312] Clause 115: The method according to Clause 114, wherein deriving the Rice parameter scaling value comprises calculating (StatCoeff[idx]≧T)?P2:P1, where idx represents the color component, StatCoeff[idx] represents the current value for the history counter, and T, P1, and P2 represent the input values.

[0347]

[0313] Clause 116: The method according to Clause 115, wherein the input values ​​for T, P1, and P2 are predetermined.

[0348]

[0314] Clause 117: The method according to Clause 115, wherein input values ​​for T, P1, and P2 are signaled in the video data.

[0349]

[0315] Clause 118: The method according to any one of Clauses 115 to 117, wherein T=4, P2=2 and P1=1.

[0350]

[0316] Clause 119: The method according to any one of Clauses 114 to 118, wherein deriving a rice parameter scaling value comprises calculating an aggregated history counter value representing an aggregation of history counters, including history counters for all color components, including color components of video data, and deriving a rice parameter scaling value using the aggregated history counter value.

[0351]

[0317] Clause 120: The method according to Clause 119, comprising calculating the aggregated history counter value by calculating ((StatCoeff[0]*w0)+StatCoeff[1]*w1+StatCoeff[2]*w2) / (w1+w2+w3), where StatCoeff[0] represents the first history counter of the history counters for the first color component of the color components, StatCoeff[1] represents the second history counter of the history counters for the second color component of the color components, StatCoeff[2] represents the third history counter of the history counters for the third color component of the color components, and w1, w2, and w3 represent their respective weighted values.

[0352]

[0318] Clause 121: The method according to Clause 120, wherein deriving a rice parameter scaling value is the method according to Clause 120, comprising deriving a rice parameter scaling value using (StatCoefAverage≧T)?P2:P1, where StatCoefAverage represents an aggregated historical counter value and T, P1, and P2 represent input values.

[0353]

[0319] Clause 122: The method according to Clause 121, wherein the input values ​​for T, P1, and P2 are predetermined.

[0354]

[0320] Clause 123: The method according to Clause 121, wherein input values ​​for T, P1, and P2 are signaled in the video data.

[0355]

[0321] Clause 124: The method according to any one of Clauses 121 to 123, wherein T=4, P2=2 and P1=1.

[0356]

[0322] Clause 125: The method according to any of Clauses 121 to 124, wherein w0=2, w1=1, and w2=1.

[0357]

[0323] Clause 126: The method according to any one of Clauses 114 to 125, wherein the second block comprises one of a coding tree unit (CTU), a translation unit (TU), or a sub-translation unit (sub-TU).

[0358]

[0324] Clause 127: The method according to any one of Clauses 103 to 126, wherein one or more processors are configured to decode the current coefficients using normalized values ​​of the sum of absolute values ​​in order to code the current coefficients.

[0359]

[0325] Clause 128: The method according to any one of Clauses 103 to 127, wherein one or more processors are configured to encode the current coefficients using normalized values ​​of the sum of absolute values.

[0360]

[0326] Clause 129: A device for coding video data, the device comprising a memory configured to store video data and one or more processors implemented in the circuit, wherein one or more processors are configured to calculate the sum of the absolute values ​​of a plurality of adjacent coefficients for a current coefficient for a current block of video data; calculate a base-level offset value according to at least one of the bit depth for video data or a slice type for a slice containing the current block; calculate a normalized value for the sum of absolute values ​​using the base-level offset value; and code the current coefficient using the normalized value for the sum of absolute values.

[0361]

[0327] Clause 130: The device according to Clause 129, wherein multiple adjacent coefficients include five adjacent coefficients relative to the current coefficient.

[0362]

[0328] Clause 131: The device according to any of Clauses 129 and 130, wherein the number of adjacent coefficients includes two adjacent coefficients to the right of the current coefficient, two adjacent coefficients below the current coefficient, and one adjacent coefficient to the left of the current coefficient.

[0363]

[0329] Clause 132: A device according to any one of Clauses 129 to 131, wherein one or more processors are configured to compute baseLevelOffset=(bitDepth>T)?(isIntra()?P1:P2):(isIntra()?P3:P4), where bitDepth is the bit depth for the video data, isIntra() returns a true value if the slice type for the slice is an intra-predicted slice, or a false value if the slice type for the slice is an inter-predicted slice, and T, P1, P2, P3, and P4 are their respective input values.

[0364]

[0330] Clause 133: The device described in Clause 132, wherein T=12.

[0365]

[0331] Clause 134: A device according to either Clause 132 or 133, wherein the input values ​​for T, P1, P2, P3, and P4 are predetermined.

[0366]

[0332] Clause 135: A device according to any one of Clauses 129 to 134, wherein one or more processors are configured to calculate Clip3(0,31,locSumAbs-baseLevelOffset) for calculating a normalized value for the sum of absolute values, where locSumAbs comprises the sum of absolute values ​​and baseLevelOffset comprises the base-level offset value.

[0367]

[0333] Clause 136: The device according to Clause 135, wherein one or more processors are configured to determine a rice parameter corresponding to a normalized value for the sum of absolute values ​​and to binarize the value for the current coefficient using the rice parameter in order to code the current coefficient using a normalized value for the sum of absolute values.

[0368]

[0334] Clause 137: The device according to any one of Clauses 129 to 136, wherein the current block comprises a first block, the color components of video data comprises a first sum of absolute values, and a plurality of adjacent coefficients comprises a first plurality of adjacent coefficients, wherein one or more processors are further configured to maintain a history counter representing a history of Rice parameters used to code the coefficients of the color components of video data; derive a Rice parameter scaling value for a second block of the color components of video data from the current value of the history counter without explicitly coding a value for the Rice parameter scaling value; calculate a second sum of absolute values ​​of the second plurality of adjacent coefficients for a second coefficient of the second block; calculate a scaled value for the second sum of absolute values ​​using the Rice parameter scaling value; and code the second coefficient of the second block using the scaled value for the second sum of absolute values.

[0369]

[0335] Clause 138: The device according to Clause 137, wherein one or more processors are configured to calculate (StatCoeff[idx]≧T)?P2:P1 in order to derive a Rice parameter scaling value, where idx represents a color component, StatCoeff[idx] represents the current value for a history counter, and T, P1, and P2 represent input values.

[0370]

[0336] Clause 139: A device according to any one of Clauses 129 to 138, wherein one or more processors are configured to encode the current coefficients using normalized values ​​of the sum of absolute values, or to decode the current coefficients using normalized values ​​of the sum of absolute values.

[0371]

[0337] Clause 140: The device described in any of Clauses 129 to 139, further comprising a display configured to display decoded video data.

[0372]

[0338] Clause 141: A device as described in any of Clauses 129 to 140, comprising one or more of the following: a camera, a computer, a mobile device, a broadcast receiver device, or a set-top box.

[0373]

[0339] Clause 142: A computer-readable storage medium storing instructions, wherein, when the instructions are executed, the instructions cause a processor of a device for coding video data to calculate the sum of the absolute values ​​of a plurality of adjacent coefficients for a current coefficient for a current block of video data; calculate a base-level offset value according to at least one of the bit depth for video data or the slice type for a slice containing the current block; calculate a normalized value for the sum of absolute values ​​using the base-level offset value; and code the current coefficient using the normalized value for the sum of absolute values.

[0374]

[0340] Clause 143: A device for coding video data, the device comprising means for calculating the sum of the absolute values ​​of a plurality of adjacent coefficients for a current coefficient for a current block of video data; means for calculating a base-level offset value according to at least one of a bit depth for video data or a slice type for a slice containing the current block; means for calculating a normalized value for the sum of absolute values ​​using the base-level offset value; and means for coding the current coefficient using the normalized value for the sum of absolute values.

[0375]

[0341] In accordance with the above examples, it should be noted that some of the actions or events of any of the techniques described herein may be performed in different sequences, added, merged, or completely excluded (for example, not all described actions or events are necessary for the practice of this technique). Furthermore, in some examples, the actions or events may not be performed sequentially, but rather simultaneously, for example, through multithreading, interrupt handling, or across multiple processors.

[0376]

[0342] In one or more examples, the described functions may be implemented in hardware, software, firmware, or any combination thereof. If implemented in software, the functions may be stored on or transmitted via computer-readable media as one or more instructions or codes and executed by a hardware-based processing unit. Computer-readable media may include computer-readable storage media corresponding to tangible media such as data storage media, or communication media including any media that facilitates the transfer of computer programs from one place to another according to a communication protocol, for example. Thus, computer-readable media may generally correspond to (1) non-transient tangible computer-readable storage media, or (2) communication media such as signals or carrier waves. Data storage media may be any available media that can be accessed by one or more computers or one or more processors to retrieve instructions, codes and / or data structures for implementation of the techniques described herein. Computer program products may include computer-readable media.

[0377]

[0343] As an example, and not an limitation, such computer-readable storage media may include RAM, ROM, EEPROM®, CD-ROM or other optical disk storage, magnetic disk storage or other magnetic storage devices, flash memory, or any other medium that can be used to store desired program code in the form of instructions or data structures and can be accessed by a computer. Any connection is also appropriately called a computer-readable medium. For example, if instructions are transmitted from a website, server or other remote source using coaxial cable, fiber optic cable, twisted pair, digital subscriber line (DSL), or wireless technologies such as infrared, radio, and microwave, then coaxial cable, fiber optic cable, twisted pair, DSL, or wireless technologies such as infrared, radio, and microwave are included in the definition of a medium. However, it should be understood that computer-readable storage media and data storage media refer to non-temporary, tangible storage media instead of connections, carriers, signals, or other temporary media. As used herein, the terms "disk" and "disc" include Compact Disc (CD), LaserDisc® (disc), Optical Disc (disc), Digital Multipurpose Disc (disc) (DVD), Floppy Disk (disk), and Blu-ray Disc (disc), where a disk typically reproduces data magnetically and a disc reproduces data optically using a laser. Any combination of the above should also be included within the scope of computer-readable media.

[0378]

[0344] Instructions may be executed by one or more processors, such as one or more digital signal processors (DSPs), general-purpose microprocessors, application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other equivalent integrated or discrete logic circuits. Accordingly, the terms “processor” and “processing circuit” as used herein may refer to any of the above-described structures or any other structure suitable for implementing the techniques described herein. Furthermore, in some embodiments, the functions described herein may be provided within dedicated hardware and / or software modules configured for encoding and decoding, or incorporated into a composite codec. The techniques may also be fully implemented in one or more circuits or logic elements.

[0379]

[0345] The techniques of the Disclosure may be implemented in a wide variety of devices or apparatus, including wireless handsets, integrated circuits (ICs) or sets of ICs (e.g., chipsets). In this Disclosure, various components, modules, or units have been described to highlight the functional aspects of devices configured to implement the techniques disclosed, but these components, modules, or units do not necessarily require implementation by different hardware units. Rather, as described above, the various units may be combined in a codec hardware unit, including one or more processors described above, along with suitable software and / or firmware, or provided by a set of interoperable hardware units.

[0380]

[0346] Various examples have been described. These and other examples fall within the scope of the following claims. The invention described in the original claims of this application is listed below. [C1] A method for coding video data, Calculate the sum of the absolute values ​​of multiple adjacent coefficients for the current coefficient in the current block of video data, Calculating a base-level offset value according to at least one of the bit depth for the video data or the slice type for the slice containing the current block, Using the aforementioned base-level offset value, calculate the normalized value of the sum of absolute values, Coding the current coefficient using the normalized value of the sum of absolute values, A method that includes [a certain feature]. [C2] The method according to C1, wherein the plurality of adjacent coefficients include five adjacent coefficients with respect to the current coefficient. [C3] The method according to C1, wherein the plurality of adjacent coefficients include two adjacent coefficients to the right of the current coefficient, two adjacent coefficients below the current coefficient, and one adjacent coefficient to the left of the current coefficient. [C4] Calculating the base level offset value comprises calculating baseLevelOffset=(bitDepth>T)?(isIntra()?P1:P2):(isIntra()?P3:P4), Here, baseLevelOffset is the base level offset value, bitDepth is the bit depth for the video data, isIntra() returns a true value if the slice type for the slice is an intra-predicted slice, or a false value if the slice type for the slice is an inter-predicted slice, and T, P1, P2, P3, and P4 are their respective input values. The method described in C1. [C5] The method described in C4, where T=12. [C6] The method according to C5, where P1=5, P2=10, P3=6, and P4=20. [C7] The method according to C5, wherein P1=5, P2=10, P3=10, and P4=20. [C8] The input values ​​for T, P1, P2, P3, and P4 are predetermined, as described in C4. [C9] The method according to C4, wherein the input values ​​for T, P1, P2, P3, and P4 are signaled in the bitstream. [C10] The method according to C1, wherein calculating the normalized value of the sum of absolute values ​​comprises calculating Clip3(0,31,locSumAbs-baseLevelOffset), where locSumAbs is the sum of absolute values ​​and baseLevelOffset is the base-level offset value. [C11] Coding the current coefficient using the normalized value of the sum of absolute values ​​is The Rice parameter is determined using the normalized value of the sum of absolute values, To form a binarized value, the value for the current coefficient is binarized using the Rice parameter, A method of C1 comprising: [C12] The current block comprises a first block, the color components of the video data comprise the first block, the sum of absolute values ​​comprises a first sum of absolute values, the plurality of adjacent coefficients comprises a first plurality of adjacent coefficients, and the method is Maintain a history counter representing the history of the Rice parameters used to code the coefficients of the color components of the video data, The rice parameter scaling value for the second block of the color components of the video data is derived from the current value of the history counter without explicitly coding the value for the rice parameter scaling value, Calculate the second sum of the absolute values ​​of a second set of adjacent coefficients for the second coefficient of the second block, Using the aforementioned rice parameter scaling value, the scaled value for the second sum of absolute values ​​is calculated, Coding the second coefficient of the second block using the scaled value of the second sum of absolute values, A method of C1 that further includes the following: [C13] The derivation of the Rice parameter scaling value comprises calculating (StatCoeff[idx]≧T)?P2:P1, Here, idx represents the color component, StatCoeff[idx] represents the current value for the history counter, and T, P1, and P2 represent the input values. The method described in C12. [C14] The input values ​​for T, P1, and P2 are predetermined, as described in C13. [C15] The method according to C13, wherein the input values ​​for T, P1, and P2 are signaled in the video data. [C16] The method described in C13, where T=4, P2=2 and P1=1. [C17] The deriving of the aforementioned rice parameter scaling value is Calculating an aggregated history counter value that represents an aggregation of history counters, including the history counters for all color components of the video data, including the color components; Using the aggregated history counter values, the rice parameter scaling values ​​are derived. A method for C12 comprising the following: [C18] The calculation of the aggregated history counter value comprises calculating ((StatCoeff[0]*w0)+StatCoeff[1]*w1+StatCoeff[2]*w2) / (w1+w2+w3), Here, StatCoeff[0] represents the first history counter of the history counters for the first color component of the color components, StatCoeff[1] represents the second history counter of the history counters for the second color component of the color components, StatCoeff[2] represents the third history counter of the history counters for the third color component of the color components, and w1, w2, and w3 represent their respective weighting values. Method C17. [C19] The deriving of the rice parameter scaling value comprises deriving the rice parameter scaling value using (StatCoefAverage≧T)?P2:P1, Here, StatCoefAverage represents the aggregated historical counter value, and T, P1, and P2 represent the input values. Methods described in C18. [C20] The input values ​​for T, P1, and P2 are predetermined, as described in C19. [C21] The method according to C19, wherein the input values ​​for T, P1, and P2 are signaled in the video data. [C22] The method described in C19, wherein T=4, P2=2 and P1=1. [C23] The method described in C19, where w0=2, w1=1, and w2=1. [C24] The method according to C12, wherein the second block comprises one of a coding tree unit (CTU), a conversion unit (TU), or a sub-conversion unit (sub-TU). [C25] The method of C1, wherein coding the current coefficients comprises decoding the current coefficients using the normalized values ​​of the sum of absolute values. [C26] The method of C1, wherein coding the current coefficients comprises coding the current coefficients using the normalized values ​​of the sum of absolute values. [C27] A device for coding video data, A memory configured to store video data, One or more processors implemented in the circuit, The one or more processors are equipped with Calculate the sum of the absolute values ​​of multiple adjacent coefficients for the current coefficient in the current block of video data, Calculating a base-level offset value according to at least one of the bit depth for the video data or the slice type for the slice containing the current block, Using the aforementioned base-level offset value, calculate the normalized value of the sum of absolute values, Coding the current coefficient using the normalized value of the sum of absolute values, A device configured to perform the following actions. [C28] The device according to C27, wherein the plurality of adjacent coefficients include five adjacent coefficients relative to the current coefficient. [C29] The device according to C27, wherein the plurality of adjacent coefficients include two adjacent coefficients to the right of the current coefficient, two adjacent coefficients below the current coefficient, and one adjacent coefficient to the left of the current coefficient. [C30] In order to calculate the base level offset value, one or more processors are configured to calculate baseLevelOffset=(bitDepth>T)?(isIntra()?P1:P2):(isIntra()?P3:P4), Here, baseLevelOffset comprises the base level offset value, bitDepth comprises the bit depth for the video data, isIntra() returns a true value if the slice type for the slice is an intra-predicted slice, or a false value if the slice type for the slice is an inter-predicted slice, and T, P1, P2, P3, and P4 each comprise their respective input values. The device described in C27. [C31] The device described in C30, where T=12. [C32] The input values ​​for T, P1, P2, P3, and P4 are predetermined, as described in C30. [C33] The device according to C27, wherein one or more processors are configured to calculate Clip3(0,31,locSumAbs-baseLevelOffset) for the sum of absolute values, where locSumAbs is the sum of absolute values ​​and baseLevelOffset is the base-level offset value. [C34] In order to code the current coefficient using the normalized value of the sum of absolute values, one or more processors The Rice parameter is determined using the normalized value of the sum of absolute values, To form a binarized value, the value for the current coefficient is binarized using the Rice parameter, A device as described in C27, configured to perform the following actions. [C35] The current block comprises a first block, the color components of the video data comprise the first block, the sum of absolute values ​​comprises a first sum of absolute values, and the plurality of adjacent coefficients comprises a first plurality of adjacent coefficients, The one or more processors described above are: Maintain a history counter representing the history of the Rice parameters used to code the coefficients of the color components of the video data, The rice parameter scaling value for the second block of the color components of the video data is derived from the current value of the history counter without explicitly coding the value for the rice parameter scaling value, Calculate the second sum of the absolute values ​​of a second set of adjacent coefficients for the second coefficient of the second block, Using the aforementioned rice parameter scaling value, the scaled value for the second sum of absolute values ​​is calculated, Coding the second coefficient of the second block using the scaled value of the second sum of absolute values, A device as described in C27, further configured to perform the following actions. [C36] In order to derive the Rice parameter scaling value, one or more processors are configured to calculate (StatCoeff[idx]≧T)?P2:P1, Here, idx represents the color component, StatCoeff[idx] represents the current value for the history counter, and T, P1, and P2 represent the input values. The device described in C35. [C37] The device according to C27, wherein one or more processors are configured to encode the current coefficients using the normalized value of the sum of absolute values, or to decode the current coefficients using the normalized value of the sum of absolute values. [C38] The device described in C27, further comprising a display configured to display decoded video data. [C39] The device described in C27, comprising one or more of a camera, a computer, a mobile device, a broadcast receiver device, or a set-top box. [C40] A device for coding video data, A means for calculating the sum of the absolute values ​​of multiple adjacent coefficients for the current coefficient in the current block of video data, Means for calculating a base-level offset value according to at least one of the bit depth for the video data or the slice type for the slice containing the current block, Means for calculating a normalized value for the sum of absolute values ​​using the base level offset value, Means for coding the current coefficients using the normalized value of the sum of absolute values, A device equipped with the following features.

Claims

1. A method for coding video data, Calculate the sum of the absolute values ​​of multiple adjacent coefficients for the current coefficient in the current block of video data, A base-level offset value is calculated according to the bit depth of the video data and the slice type of the slice containing the current block, wherein the slice type indicates whether the slice is intra-predictively coded or inter-predictively coded. Using the aforementioned base-level offset value, the aforementioned sum of absolute values ​​is normalized, Determining the Rice parameter based on the normalized absolute value, The current coefficient is coded using the aforementioned Rice parameter, A method that includes [a certain feature].

2. The method according to claim 1, wherein the plurality of adjacent coefficients include five adjacent coefficients with respect to the current coefficient, and the plurality of adjacent coefficients include two adjacent coefficients to the right of the current coefficient, two adjacent coefficients below the current coefficient, and one adjacent coefficient to the lower right of the current coefficient.

3. Calculating the aforementioned base level offset value involves calculating baseLevelOffset = (bitDepth > T) ? (isIntra() ? P1 : P2 ): (isIntra() ? P3 : P4), Here, baseLevelOffset is the base level offset value, bitDepth is the bit depth for the video data, isIntra() returns true if the slice type for the slice is an intra-predicted slice, or false if the slice type for the slice is an inter-predicted slice, T, P1, P2, P3, and P4 are their respective input values, and the question mark operator of an expression of the form condition ? X:Y returns the value of X if the condition is true, and the value of Y if the condition is false. The method according to claim 1.

4. The method according to claim 3, wherein T = 12.

5. The method according to claim 4, wherein P1 = 5, P2 = 10, P3 = 6, and P4 = 20, or P1 = 5, P2 = 10, P3 = 10, and P4 = 20.

6. The method according to claim 3, wherein the input values ​​for T, P1, P2, P3, and P4 are predetermined, or the input values ​​for T, P1, P2, P3, and P4 are signaled in the bitstream.

7. The method according to claim 1, wherein calculating the normalized value of the sum of absolute values ​​comprises calculating Clip3(0, 31, locSumAbs - baseLevelOffset), where locSumAbs comprises the sum of absolute values ​​and baseLevelOffset comprises the base-level offset value.

8. The method according to claim 1, wherein coding the current coefficients using the normalized values ​​for the sum of absolute values ​​further comprises binarizing the values ​​for the current coefficients using the Rice parameter to form a binarized value.

9. The current block comprises a first block, the color components of the video data comprise the first block, the sum of absolute values ​​comprises a first sum of absolute values, the plurality of adjacent coefficients comprises a first plurality of adjacent coefficients, and the method is Maintain a history counter representing the history of the Rice parameters used to code the coefficients of the color components of the video data, The Rice parameter scaling value for the second block of the color components of the video data is derived from the current value of the history counter without explicitly coding the value for the Rice parameter scaling value, Calculating the second sum of the absolute values ​​of a second set of adjacent coefficients for the second coefficient of the second block, Using the aforementioned rice parameter scaling value, calculate the scaled value for the second sum of absolute values, Coding the second coefficient of the second block using the scaled value of the second sum of absolute values, The method according to claim 1, further comprising:

10. Deriving the aforementioned rice parameter scaling value involves calculating (StatCoeff[idx]≧T)? P2:P1, Here, idx represents the color component, StatCoeff[idx] represents the current value for the history counter, and T, P1, and P2 represent the input values. Here, the input values ​​for T, P1, and P2 are predetermined, or the input values ​​for T, P1, and P2 are signaled in the video data. The method according to claim 9.

11. The deriving of the aforementioned rice parameter scaling value is The calculation of the aggregated history counter value represents an aggregation of history counters, including the history counters for all color components of the video data, and wherein the calculation of the aggregated history counter value comprises calculating ((StatCoeff[0] * w0) + StatCoeff[1] * w1 + StatCoeff[2] * w2) / (w1 + w2 + w3), where StatCoeff[0] represents the first history counter of the history counters for the first color component of the color components, StatCoeff[1] represents the second history counter of the history counters for the second color component of the color components, StatCoeff[2] represents the third history counter of the history counters for the third color component of the color components, and w1, w2, and w3 represent their respective weighted values. The method for deriving the rice parameter scaling value is to use the aggregated history counter value, wherein the method for deriving the rice parameter scaling value is to use (StatCoefAverage ≥ T) ? P2:P1 to derive the rice parameter scaling value, wherein StatCoefAverage represents the aggregated history counter value, and T, P1, and P2 represent input values. The method according to claim 9, comprising:

12. The method according to claim 1, wherein coding the current coefficients comprises decoding the current coefficients using the normalized value of the sum of absolute values, or coding the current coefficients comprises encoding the current coefficients using the normalized value of the sum of absolute values.

13. A device for coding video data, A memory configured to store video data, One or more processors implemented in the circuit, The one or more processors are equipped with Calculate the sum of the absolute values ​​of multiple adjacent coefficients for the current coefficient in the current block of video data, A base-level offset value is calculated according to the bit depth of the video data and the slice type of the slice containing the current block, wherein the slice type indicates whether the slice is intra-predictively coded or inter-predictively coded. Using the aforementioned base-level offset value, the aforementioned sum of absolute values ​​is normalized, Determining the Rice parameter based on the normalized absolute value, The current coefficient is coded using the aforementioned Rice parameter, A device configured to perform the following actions.

14. The device according to claim 13, wherein the processor is configured to perform the method described in any one of claims 2 to 12.

15. The device according to claim 13, wherein the device comprises one or more of a camera, a computer, a mobile device, a broadcast receiver device, or a set-top box.

16. The device according to claim 14, wherein the device comprises one or more of a camera, a computer, a mobile device, a broadcast receiver device, or a set-top box.

Images