Adaptive derivation of Rice parameter values ​​for high-bit depth video coding

Abstract

An exemplary device for binarizing video data includes a memory configured to store the video data and one or more processors implemented in circuitry and configured to: calculate a local sum of absolute values ​​of coefficients neighboring a current coefficient of a current block of the video data (a locSumAbs value), derive a shift value from the locSumAbs value, normalize the locSumAbs value using the shift value, determine a Rice parameter using the normalized locSumAbs value, and binarize or de-binarize the current coefficient using the Rice parameter. Thus, these techniques may enable more appropriate Rice parameter value selection when performing context-adaptive binary arithmetic coding (CABAC) and binarizing high-bit-depth data.

Description

Technical Field

[0001] This application claims priority to U.S. Patent Application No. 17 / 494,418, filed Oct. 5, 2021, as well as U.S. Provisional Patent Application No. 63 / 088,010, filed Oct. 6, 2020, and U.S. Provisional Patent Application No. 63 / 090,615, filed Oct. 12, 2020, the entire contents of each of which are incorporated herein by reference. U.S. Patent Application No. 17 / 494,418, filed Oct. 5, 2021, claims the benefit of U.S. Provisional Patent Application No. 63 / 088,010, filed Oct. 6, 2020, and U.S. Provisional Patent Application No. 63 / 090,615, filed Oct. 12, 2020.

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

Background Art

[0003] Digital video capabilities can be incorporated into a wide range of devices, including digital television, digital direct broadcast systems, wireless broadcast systems, personal digital assistants (PDAs), laptop or desktop computers, tablet computers, electronic book readers, digital cameras, digital recording devices, digital media players, video gaming devices, video game consoles, cellular or satellite radiotelephones, so-called "smartphones," video teleconferencing devices, video streaming devices, and the like. Digital video devices implement video coding techniques, such as those described in the 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), and extensions to such standards. By implementing such video coding techniques, video devices can transmit, receive, encode, decode, and / or store digital video information more efficiently.

[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. Video blocks in an intra-coded (I) slice of a picture are coded using spatial predictions for reference samples in adjacent blocks within the same picture. Video blocks in an inter-coded (P or B) slice of a picture may use spatial predictions for reference samples in adjacent blocks within the same picture or temporal predictions for reference samples in other reference pictures. Pictures may be called frames, and reference pictures may be called reference frames. [Overview of the project] [Means for solving the problem]

[0005] Generally, this disclosure describes techniques for adaptively deriving Rice parameter values ​​for regular residual coding (RRC) in high-bit depth video coding. Specifically, these techniques generally include deriving a shifted value from a calculated local sum of absolute values ​​(locSumAbs value), normalizing the locSumAbs value using the shifted value, and deriving the Rice parameter from the normalized locSumAbs value. These techniques may be incorporated into extensions of ITU-T H.266 / Variable-Purpose Video Coding (VVC) or other video coding standards.

[0006] For example, a method for binarizing video data includes the steps of: calculating a local sum (locSumAbs value) of the absolute values ​​of the coefficients adjacent to the current coefficient in the current block of video data; deriving a shift value from the locSumAbs value; normalizing the locSumAbs value using the shift value to produce a normalized locSumAbs value; determining the rice parameter using the normalized locSumAbs value; and binarizing or inversely binarizing the current coefficient using the rice parameter.

[0007] In another example, a device for binarizing video data includes a memory configured to store the video data, and one or more processors implemented in the circuit and configured to calculate a local sum of the absolute values ​​of the coefficients adjacent to the current coefficient in the current block of video data (locSumAbs value), derive a shift value from the locSumAbs value, normalize the locSumAbs value using the shift value to produce a normalized locSumAbs value, determine a rice parameter using the normalized locSumAbs value, and binarize or inversely binarize the current coefficient using the rice parameter.

[0008] In another example, a computer-readable storage medium stores instructions that, when executed, cause the processor to calculate the local sum of the absolute values ​​of the coefficients adjacent to the current coefficient in the current block of video data (locSumAbs value), derive a shift value from the locSumAbs value, normalize the locSumAbs value using the shift value to produce a normalized locSumAbs value, determine the rice parameter using the normalized locSumAbs value, and binarize or inversely binarize the current coefficient using the rice parameter.

[0009] In another example, a device for binarizing video data includes means for calculating a local sum (locSumAbs value) of the absolute values ​​of the coefficients adjacent to the current coefficient in the current block of video data; means for deriving a shift value from the locSumAbs value; means for normalizing the locSumAbs value using the shift value to produce a normalized locSumAbs value; means for determining the rice parameter using the normalized locSumAbs value; and means for binarizing or inversely binarizing the current coefficient using the rice parameter.

[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] Block diagram shows an exemplary video encoding and decoding system capable of performing the techniques of this disclosure. [Figure 2A] This is a conceptual diagram illustrating an exemplary quad-binary tree (QTBT) structure. [Figure 2B] This is a conceptual diagram showing the corresponding coding tree unit (CTU). [Figure 3] A block diagram illustrating a video encoder capable of performing the techniques of this disclosure. [Figure 4] A block diagram illustrating an exemplary video decoder capable of performing the techniques of this disclosure. [Figure 5] This is a conceptual diagram showing an exemplary set of adjacent coefficients that can be used when calculating the local sum of adjacent absolute values ​​(localSumAbs) for the current coefficient. [Figure 6] This flowchart shows an exemplary method for encoding the current block using the technique of the present disclosure. [Figure 7] This flowchart shows an exemplary method for decoding the current block using the technique of the present disclosure. [Figure 8]This flowchart shows an exemplary method for binarizing video data using the technique of this disclosure. [Figure 9] This flowchart illustrates an exemplary method for de-binarizing video data using the technique described herein. [Modes for carrying out the invention]

[0012] 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 finalized in April 2013 by the Joint Collaboration Team on Video Coding (JCT-VC) of the ITU-T Video Coding Experts Group (VCEG) and the ISO / IEC Motion Picture Experts Group (MPEG).

[0013] The Joint Video Experts Team (JVET), a joint team formed by MPEG and ITU-T Research Group 16's VCEG, has recently been working on a new video coding standard that will become known as Versatile Video Coding (VVC). The primary objective of VVC is to provide a significant improvement in compression performance over the existing HEVC standard, supporting higher-quality video services and the deployment of emerging applications such as 360° immersive multimedia and high dynamic range (HDR) video. Development of the VVC standard was completed in 2020. A draft of VVC can be found at phenix.it-sudparis.eu / jvet / doc_end_user / documents / 19_Teleconference / wg11 / JVET-S2001-v17.zip.

[0014] This disclosure acknowledges that in one exemplary draft of the VVC specification, the Rice parameter has been extensively tested for encoding 8-bit depth or 10-bit depth video sources. In the exemplary design, the Rice parameter value depends on the value of locSumAbs and is limited to the range of 0 to 3 by clipping. As the bit depth of the input video increases, expanded precision is enabled or the quantization parameter is set very low, which can significantly increase the range of coefficients, and therefore the locSumAbs value. In such cases, some ranges of allowable Rice parameter values ​​in the exemplary draft of VVC are insufficient. This limitation can cause a degradation in coding performance in VVC and other video coding standards when using high-bit-depth coding. Therefore, this disclosure describes, for example, a technique for high-bit-depth video coding that may thereby increase the Rice parameter range.

[0015] Figure 1 is a block diagram illustrating an exemplary video coding and decoding system 100 capable of performing the techniques of the present disclosure. The techniques of the present disclosure generally concern coding (encoding and / or decoding) video data. Generally, video data includes any data for processing video. Thus, video data may include raw, uncoded video, coded video, decoded (e.g., reconstructed) video, and video metadata such as signaling data.

[0016] As shown in Figure 1, the system 100 includes, in this example, a source device 102 that provides encoded video data to be decoded and displayed by a destination device 116. Specifically, the source device 102 provides 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, and so on. 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.

[0017] In the example in Figure 1, the source device 102 includes a video source 104, memory 106, a video encoder 200, and an output interface 108. The destination device 116 includes an input interface 122, a video decoder 300, memory 120, and a display device 118. According to 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 techniques for adaptively deriving RICE parameters for high-bit-depth video coding. Thus, the source device 102 represents an example of a video coding 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 configurations. 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.

[0018] System 100, as shown in Figure 1, is merely an example. In general, any digital video coding and / or decoding device may perform techniques for adaptively deriving RICE parameters for high-bit-depth video coding. Source device 102 and destination device 116 are merely examples of coding devices such that source device 102 generates coded video data for transmission to destination device 116. This disclosure refers to a device that performs coding (encoding and / or decoding) of data as a “coding” device. Thus, video encoder 200 and video decoder 300 represent examples of coding devices, specifically, video encoder and video decoder, respectively. In some examples, source device 102 and destination device 116 may operate in a substantially symmetrical manner such that each of source device 102 and destination device 116 includes video coding and decoding components. Thus, system 100 may support one-way or two-way video transmission between source device 102 and destination device 116 for, for example, video streaming, video playback, video broadcasting, or video telephony.

[0019] Generally, video source 104 represents a source of video data (i.e., raw, uncoded video data), provides a continuous series of pictures (also referred to as "frames") of the video data to video encoder 200, and video encoder 200 encodes the data for the pictures. The video source 104 of source device 102 can 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, video source 104 can generate computer graphics-based data as source video, or a combination of live video, archived video, and computer-generated video. In each case, video encoder 200 encodes the captured, pre-captured, or computer-generated video data. Video encoder 200 can reorder the pictures from the received order (sometimes referred to as "display order") to the coding order for coding. Video encoder 200 can generate a bitstream including the encoded video data. Then, source device 102 can output the encoded video data onto computer-readable medium 110 via output interface 108 for reception and / or retrieval, for example, by input interface 122 of destination device 116.

[0020] 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. Additionally or alternatively, 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 of memory 106, 120 may be allocated as one or more video buffers for storing, for example, raw, decoded, and / or encoded video data.

[0021] Computer-readable medium 110 may represent any type of medium or device capable of transporting encoded video data from source device 102 to destination device 116. In one example, computer-readable medium 110 represents a communication medium that enables source device 102 to directly transmit encoded video data to destination device 116 in real time via, for example, a radio frequency network or a computer-based network. Output interface 108 may modulate a transmission signal including the encoded video data in accordance with a communication standard such as a wireless communication protocol, and input interface 122 may demodulate the received transmission signal. The communication medium may comprise any wireless or wired communication medium, such as the 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 a router, a switch, a base station, or any other device that may be useful for facilitating communication from source device 102 to destination device 116.

[0022] In some examples, source device 102 may output the encoded data from output interface 108 to storage device 112. Similarly, destination device 116 may access the encoded data from storage device 112 via input interface 122. Storage device 112 may include any of a variety of distributed or locally accessible data storage media, such as a hard drive, a Blu-ray disk, a DVD, a CD-ROM, a flash memory, a volatile or non-volatile memory, or any other suitable digital storage media for storing the encoded video data.

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

[0024] The file server 114 may 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 file transfer protocol services (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.

[0025] 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 suitable for accessing the encoded video data stored on 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 other such protocols for retrieving media data.

[0026] 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, source device 102 may include an SoC device for performing functions related to the video encoder 200 and / or output interface 108, and destination device 116 may include an SoC device for performing functions related to the video decoder 300 and / or input interface 122.

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

[0028] 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 and 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 various 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.

[0029] 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 multiplexed streams containing both audio and video in a common data stream. Where applicable, the MUX-DEMUX unit may comply with the ITU H.223 Multiplexer Protocol or other protocols such as the User Datagram Protocol (UDP).

[0030] The video encoder 200 and video decoder 300 may each be implemented as one or more suitable encoder and / or decoder circuits, such as one or more microprocessors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), discrete logic, software, hardware, firmware, or any combination thereof. When the technique is partially implemented in software, the device may store instructions for the software in a suitable non-temporary computer-readable medium and execute the instructions in hardware using one or more processors to perform the technique of this disclosure. Each of the video encoder 200 and video decoder 300 may be included in 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 include an integrated circuit, a microprocessor, and / or a wireless communication device such as a cellular telephone.

[0031] 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 Versatile Video Coding (VVC). A draft of the VVC standard is described in Bross et al., "Versatile Video Coding (Draft 9)," ITU-T SG 16 WP 3 and the Joint Video Experts Team (JVET) of ISO / IEC JTC 1 / SC 29 / WG 11, 18th meeting, April 15-24, JVET-R2001-v8 (hereinafter referred to as "VVC Draft 9"). However, the techniques of this disclosure are not limited to any particular coding standard.

[0032] Generally, the video encoder 200 and video decoder 300 can perform block-based coding of a picture. The term “block” generally refers to a structure containing data to be processed (e.g., 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 can 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 can code luminance and chrominance components, and the chrominance component may contain both red and blue chrominance components. In some examples, the video encoder 200 converts the received RGB-formatted data to a YUV representation prior to encoding, and the video decoder 300 converts the YUV representation to RGB format. Alternatively, pre-processing units and post-processing units (not shown) may perform these conversions.

[0033] 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 (e.g., predictive and / or residual coding) to include the process of encoding or decoding the data for that block. An encoded video bitstream generally contains a set of values ​​for syntax elements representing 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.

[0034] 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 coding tree units (CTUs) into CUs according to a quadtree structure. That is, the video coder divides the CTUs and CUs into four equal, non-overlapping squares, and each node in the quadtree 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, a residual quadtree (RQT) represents a division of TUs. In HEVC, PUs represent intra-prediction data, and TUs represent residual data. Intra-predicted CUs contain intra-prediction information, such as intra-mode indications.

[0035] 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-binary tree (QTBT) structure or a multi-type tree (MTT) structure. The QTBT structure eliminates the concept of multiple division types, such as the distinction between CU, PU, ​​and TU in HEVC. The QTBT structure includes two levels: a first level divided according to quad-tree divisions and a second level divided according to binary tree divisions. The root node of the QTBT structure corresponds to a CTU. The leaf nodes of the binary tree correspond to coding units (CUs).

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

[0037] In some examples, the video encoder 200 and video decoder 300 may use a single QTBT or MTT structure to represent each of the luminance and chrominance components, 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).

[0038] The video encoder 200 and video decoder 300 may be configured to use a quadtree partition, QTBT partition, MTT partition, or other partitioning structure per HEVC. For illustrative purposes, the description of the technique in this disclosure is presented in relation to the QTBT partition. However, it should be understood that the technique in this disclosure may also be applicable to video coders configured to use a quadtree partition or other types of partitions.

[0039] In some examples, a CTU includes a coding tree block (CTB) of a lumen sample, two corresponding CTBs of a chroma sample of a picture having three sample arrays, or a CTB of a sample of a picture coded using three separate color planes and syntax structures used to code a monochrome picture or sample. A 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. Components can be an array from one of three arrays (lumen and two chroma) of a picture in a 4:2:0, 4:2:2, or 4:4:4 color format, or a single sample from that array, or an array of a picture in a monochrome format, or a single sample from that array. In some examples, a 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.

[0040] 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 or row in a picture. A tile column refers to a rectangular area of ​​CTUs with 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 with a height specified by a syntax element (e.g., in a picture parameter set) and a width equal to the width of the picture.

[0041] In some examples, a tile may be divided into multiple bricks, each brick containing one or more CTU rows within the tile. A tile that is not divided into multiple bricks may also be called a brick. However, a brick that is a true subset of a tile may not be called a tile.

[0042] Bricks within a picture can also be arranged in slices. A slice can be an integer number of bricks in a picture that can exclusively be contained within a single Network Abstraction Layer (NAL) unit. In some examples, a slice may contain either a certain number of complete tiles or only a continuous sequence of complete bricks of a single tile.

[0043] This disclosure may interchangeably use "N×N" and "N by N," e.g., 16×16 samples or 16 by 16 samples, to refer to the sample dimension of a block (such as a CU or other video block) in terms of vertical and horizontal dimensions. 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. The 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.

[0044] The video encoder 200 encodes video data for CUs that represent prediction and / or residual information, as well as other information. The prediction information indicates how the CUs will be predicted to form prediction blocks for the CUs. The residual information generally represents the sample-by-sample difference between the samples of the CUs prior to encoding and the samples of the prediction blocks.

[0045] To predict a CU, the video encoder 200 can 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 previously coded data of the same picture. To perform inter-prediction, the video encoder 200 can generate prediction blocks using one or more motion vectors. The video encoder 200 can generally perform motion search to identify a reference block that exactly matches the CU with respect to the difference between the CU and the reference block. The video encoder 200 can 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 exactly matches the current CU. In some examples, the video encoder 200 can predict the current CU using unidirectional or bidirectional prediction.

[0046] 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 irregular motion types.

[0047] To perform intra-prediction, the video encoder 200 may select an intra-prediction mode to generate a prediction block. Several examples of VVCs provide 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 to predict a sample of the current block. Such samples could generally be above, above and to the left of, or to the left of, the current block in the same picture as the current block, assuming that the video encoder 200 codes CTUs and CUs in raster scanning order (left to right, top to bottom).

[0048] 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 about the corresponding mode. In the case of unidirectional or bidirectional interprediction, for example, the video encoder 200 may encode the motion vectors using advanced motion vector prediction (AMVP) or merge mode. The video encoder 200 may use similar modes to encode the motion vectors for affine motion compensation mode.

[0049] 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 a residual block, represents the sample-by-sample difference between the block and the predicted block for that block formed using the corresponding prediction mode. The video encoder 200 may apply one or more transformations to the residual block to generate transformation data in the transformation domain rather than the sample domain. 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. In addition, the video encoder 200 may apply a second-order transform such as a mode-dependent non-separable secondary transform (MDNSST), signal-dependent transform, or Karhunen-Loeve transform (KLT) following the first transformation. Following the application of one or more transformations, the video encoder 200 generates transformation coefficients.

[0050] As described above, following any transformation to generate the transformation coefficients, the video encoder 200 may perform quantization of the transformation coefficients. Quantization generally refers to the process of quantizing the transformation coefficients to reduce the amount of data used to represent them as much as possible, thereby achieving further compression. 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 truncate 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.

[0051] Following quantization, the video encoder 200 may scan the transformation coefficients and generate 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 for scanning the quantized transformation coefficients to generate a serialized vector and then entropy-encode the quantized transformation coefficients of the vector. In other examples, the video encoder 200 may perform an adaptive scan. 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 that describe metadata associated with the encoded video data for use by the video decoder 300 when decoding the video data.

[0052] To perform CABAC, the video encoder 200 may first binarize the values ​​to be encoded by forming a string of binary values, also called "bins." The video encoder 200 may assign a context within a context model to each of the symbols to be transmitted, for example, each of the bins. The context may relate, for example, whether the adjacent values ​​of the symbol are zero-valued or not. Probability decisions may be based on the context assigned to the symbol.

[0053] In the case of conversion coefficient coding, the video encoder 200 and video decoder 300 may code values ​​for syntax elements that represent the level values ​​of the conversion coefficients. In some examples, such syntax elements include a significance coefficient flag (indicating whether the absolute value of the conversion coefficient level is greater than 0), a greater than 1 flag (indicating whether the absolute value of the conversion coefficient level is greater than 1), a greater than 2 flag (indicating whether the absolute value of the conversion coefficient level is greater than 2), and a residual level value representing the actual value of the conversion coefficient when the conversion coefficient level has an absolute value greater than 2. The video encoder 200 and video decoder 300 may binarize the residual level value using the Golomb Rice code and the determined Rice parameters.

[0054] The video encoder 200 and video decoder 300 may determine the Rice parameter for the current transformation coefficient using the values ​​of other transformation coefficients in the neighborhood around the current transformation coefficient. That is, the video encoder 200 and video decoder 300 may determine the Rice parameter according to the transformation coefficients adjacent to the current transformation coefficient, i.e., the neighborhood transformation coefficients. For example, the video encoder 200 and video decoder 300 may determine the Rice parameter according to the values ​​of the transformation coefficients immediately to the right of the current transformation coefficient, two positions to the right of the current transformation coefficient, below and to the right of the current transformation coefficient, immediately below and two positions below the current transformation coefficient. The video encoder 200 and video decoder 300 may calculate the sum of the absolute values ​​of these transformation coefficients, where such a sum is sometimes called the “local sum of absolute values” or “locSumAbs” value.

[0055] According to the techniques of this disclosure, instead of immediately performing a lookup for the rice parameter in a lookup table using the locSumAbs value, the video encoder 200 and video decoder 300 may derive a shift value from the locSumAbs value and normalize the locSumAbs value using the shift value. For example, the shift value may represent the number of bits by which a bitwise right shift of the locSumAbs value should be performed. The video encoder 200 and video decoder 300 may then perform a lookup for the rice parameter in a lookup table using the normalized locSumAbs value. The video encoder 200 and video decoder 300 may then binarize (or inversely binarize) the current conversion coefficient using the determined rice parameter.

[0056] 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 a picture header, block header, slice header, or sequence parameter set (SPS), picture parameter set (PPS), or video parameter set (VPS). The video decoder 300 may similarly decode such syntax data to determine how to decode the corresponding video data.

[0057] Thus, 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.

[0058] Generally, the video decoder 300 decodes the encoded video data of the bitstream by performing a process that is the reverse of the process performed by the video encoder 200. For example, the video decoder 300 may decode values ​​for syntax elements of the bitstream using CABAC in a substantially similar, but reverse, manner to the CABAC encoding process of the video encoder 200. The syntax elements may define the CUs of the CTUs by defining partitioning information for partitioning the picture into CTUs, and partitioning each CTU according to a corresponding partitioning structure such as a QTBT structure. The syntax elements may further define prediction and residual information for blocks of video data (e.g., CUs).

[0059] 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-prediction or inter-prediction) and associated prediction information (for example, motion information about inter-prediction) to form a prediction block for the block. The video decoder 300 may then synthesize 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.

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

[0061] According to the techniques of this disclosure, video coders such as video encoder 200 and video decoder 300 can be configured to perform Rice parameter derivation in an improved manner compared to conventional VVC. That is, the video encoder 200 and video decoder 300 can be configured to derive Rice parameters at various input bit depths of video data. These techniques can improve the compression efficiency of coding designs.

[0062] For example, the video encoder 200 and video decoder 300 may scale and / or normalize localSumbAbs (which may be the same as locSumAbs) to handle bit depth increases or dynamic ranges of conversion coefficients before they are used to derive the Rice parameters. For example, such scaling and / or normalization may affect equation 1517 of the VVC specification, as shown below. The amount of the scaling coefficient may depend on the input bit depth, a predefined operation bit depth, e.g., 10, or the local activity of the conversion coefficients, the block size, or the video encoder 200 may signal the value of the syntax element in the bitstream. The video encoder 200 and video decoder 300 may then clip localSumAbs to a certain range, for example, using the current clipping of localSumAbs in the VVC. Next, the video encoder 200 and video decoder 300 may use normalized and clipped localSumAbs to derive the Rice parameters using a predefined lookup table, for example, the current lookup table for VVC, Table 128. Once localSumAbs is normalized in the first step of the proposed design, the video encoder 200 and video decoder 300 may derive the Rice parameters from a predefined table, for example, Table 128 for VVC. Finally, the video encoder 200 and video decoder 300 may modify the value of localSumAbs by adding an offset to expand the dynamic range of the Rice parameter range.

[0063] The video encoder 200 and video decoder 300 may be configured according to a modified version of the VVC specification, where added text is indicated using "[added: "added text"]". 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. Given an array AbsLevel[x][y] of transformation blocks having component index cIdx and upper-left lumar location (x0, y0), the variable locSumAbs is derived as specified by the following pseudocode process. locSumAbs = 0 if( xC < ( 1 << log2TbWidth ) - 1 ) { locSumAbs += AbsLevel[ xC + 1 ][ yC ] if( xC < ( 1 << log2TbWidth ) - 2 ) locSumAbs += AbsLevel[ xC + 2 ][ yC ] if( yC < ( 1 << log2TbHeight ) - 1 ) locSumAbs += AbsLevel[ xC + 1 ][ yC + 1 ] (1517) } if( yC < ( 1 << log2TbHeight ) - 1 ) { locSumAbs += AbsLevel[ xC ][ yC + 1 ] if( yC < ( 1 << log2TbHeight ) - 2 ) locSumAbs += AbsLevel[ xC ][ yC + 2 ]} [added: "shift = (Bitdepth - b) > 0 ? Floor(Log2(a*(Bitdepth - b))) : 0 localSumAbs = (shift == 0) ? localSumAbs : (localSumAbs + (1 << (shift -1) )) >> shift"] locSumAbs = Clip3( 0, 31, locSumAbs - baseLevel * 5 ) Given the variable locSumAbs, the rice parameter cRiceParam is derived as specified in Table 128. Next, cRiceParam is refined as follows: [added: "cRiceParam = cRiceParam + c"]

[0064] In some examples, the variables a, b, and c above may be defined as follows: In one example, the variable "b" specifies the bit depth of the operation and may be set to, for example, 10; the variable "a" may be set to an integer value, for example, 4, or another value that is a power of 2; and the variable "c" may be set to the calculated shift value or derived from the shift value. The operators "<<" and ">>" represent bitwise left and right shift operations, and the "A ? B : C" operator indicates that if A is true, the value B is returned, but if A is false, the value C is returned.

[0065] In another example, localSumAbs may be scaled / normalized when it is greater than or equal to a threshold. In this case, the relevant rice parameter derivation section of the VVC may be modified accordingly as follows (where "[added: "added text"]" means an addition to the VVC): 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. Given an array AbsLevel[x][y] of transformation blocks having component index cIdx and upper-left lumar location (x0, y0), the variable locSumAbs is derived as specified by the following pseudocode process. locSumAbs = 0 if( xC < ( 1 << log2TbWidth ) - 1 ) { locSumAbs += AbsLevel[ xC + 1 ][ yC ] if( xC < ( 1 << log2TbWidth ) - 2 ) locSumAbs += AbsLevel[ xC + 2 ][ yC ] if( yC < ( 1 << log2TbHeight ) - 1 ) locSumAbs += AbsLevel[ xC + 1 ][ yC + 1 ] (1517) } if( yC < ( 1 << log2TbHeight ) - 1 ) { locSumAbs += AbsLevel[ xC ][ yC + 1 ] if( yC < ( 1 << log2TbHeight ) - 2 ) locSumAbs += AbsLevel[ xC ][ yC + 2 ]} [added: "shift = ((Bitdepth - b) > 0) && (localSumAbs - baseLevel * 5) >= T ? Floor(Log2(a*(Bitdepth - b))) : 0 localSumAbs = (shift == 0) ? localSumAbs : (localSumAbs + (1 << (shift -1) )) >> shift"] locSumAbs = Clip3( 0, 31, locSumAbs - baseLevel * 5 ) Given the variable locSumAbs, the rice parameter cRiceParam is derived as specified in Table 128. Next, cRiceParam is refined as follows: [added: "cRiceParam = cRiceParam + c"]

[0066] In this example, T is a predefined threshold. In one example, T may be set to be equal to 32. In some examples, the values ​​of variables a, b, and c may be signaled through the bitstream, or may be set according to or derived from bit depth, local statistics such as the minimum / maximum or average of the transformation coefficient values ​​in the current block, the decoded transformation, the block size, or syntax elements signaled in the bitstream.

[0067] In another example, the video encoder 200 and video decoder 300 may normalize the localSumAbs value again, for example, as follows (where "[added: "added text"]" means an addition to the VVC): 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. Given an array AbsLevel[x][y] of transformation blocks having component index cIdx and upper-left lumar location (x0, y0), the variable locSumAbs is derived as specified by the following pseudocode process. locSumAbs = 0 if( xC < ( 1 << log2TbWidth ) - 1 ) { locSumAbs += AbsLevel[ xC + 1 ][ yC ] if( xC < ( 1 << log2TbWidth ) - 2 ) locSumAbs += AbsLevel[ xC + 2 ][ yC ] if( yC < ( 1 << log2TbHeight ) - 1 ) locSumAbs += AbsLevel[ xC + 1 ][ yC + 1 ] (1517) } if( yC < ( 1 << log2TbHeight ) - 1 ) { locSumAbs += AbsLevel[ xC ][ yC + 1 ] if( yC < ( 1 << log2TbHeight ) - 2 ) locSumAbs += AbsLevel[ xC ][ yC + 2 ]} [added: "shift = ((Bitdepth - b) > 0) && (localSumAbs - baseLevel * 5) >= T ? Floor(Log2(a*(Bitdepth - b))) : 0 localSumAbs = (shift == 0) ? localSumAbs : (localSumAbs + (1 << (shift -1) )) >> shift shift1 = ((Bitdepth - b) > 0) && (localSumAbs - baseLevel * 5) >= T ? Floor(Log2(a*(Bitdepth - b))) : 0 localSumAbs = (shift1 == 0) ? localSumAbs : (localSumAbs + (1 << (shift1 -1) )) >> shift1"] locSumAbs = Clip3( 0, 31, locSumAbs - baseLevel * 5 ) Given the variable locSumAbs, the rice parameter cRiceParam is derived as specified in Table 128. Next, cRiceParam is refined as follows: [added: "cRiceParam = cRiceParam + c"]

[0068] In the example above, the video encoder 200 and video decoder 300 may set a value of c equal to (shift + shift1).

[0069] In another example, the video encoder 200 and video decoder 300 may normalize the locSumAbs value by a coefficient that depends on the magnitude of locSumAbs and the input bit depth. In this case, the video encoder 200 and video decoder 300 may use a modified technique for deriving the relevant Rice parameters (for the corresponding parts of the VVC Draft 10), modified as follows, for example, where [added: "added text"] represents an addition to the VVC Draft 10. 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. Given an array AbsLevel[x][y] of transformation blocks having component index cIdx and upper-left lumar location (x0, y0), the variable locSumAbs is derived as specified by the following pseudocode process. locSumAbs = 0 if( xC < ( 1 << log2TbWidth ) - 1 ) { locSumAbs += AbsLevel[ xC + 1 ][ yC ] if( xC < ( 1 << log2TbWidth ) - 2 ) locSumAbs += AbsLevel[ xC + 2 ][ yC ] if( yC < ( 1 << log2TbHeight ) - 1 ) locSumAbs += AbsLevel[ xC + 1 ][ yC + 1 ] (1517) } if( yC < ( 1 << log2TbHeight ) - 1 ) { locSumAbs += AbsLevel[ xC ][ yC + 1 ] if( yC < ( 1 << log2TbHeight ) - 2 ) locSumAbs += AbsLevel[ xC ][ yC + 2 ]} [added: "The variables shift and locSumAbs are derived as follows: shift = (locSumAbs * scl) >= T ? FloorLog2((locSumAbs * scl) >> N) : 0 locSumAbs = locSumAbs >> shift Next, the variable locSumAbs is updated as follows: locSumAbs = Clip3( 0, 31, locSumAbs - baseLevel * 5 ) Given the variable locSumAbs, the rice parameter cRiceParam is derived as specified in Table 128. Next, cRiceParam is refined as follows: [added: "cRiceParam = cRiceParam + shift"]

[0070] In some of the examples above, the video encoder 200 and video decoder 300 may determine the values ​​of the thresholds T, scl, and N according to the bit depth of the bitstream. Alternatively, the video encoder 200 and video decoder 300 may use predefined values ​​for T, scl, and N. Alternatively, the video encoder 200 may signal the values ​​of T, scl, and N at the sequence, picture, or slice level (for example, using a sequence parameter set (SPS), picture parameter set (PPS), adaptive parameter set (APS), or slice header), and the video decoder 300 may determine the values ​​of T, scl, and N from the signaled data.

[0071] For example, scl may be defined as follows: Scl = floorLog2(bitdepth - 10) Furthermore, T may be set to be equal to 8, and N may be set to be equal to 3.

[0072] Figures 2A and 2B are conceptual diagrams showing an exemplary quadtree-binary (QTBT) structure 130 and its corresponding coding tree unit (CTU) 132. Solid lines represent quadtree partitions, and dotted lines represent binary tree partitions. At each partition (i.e., non-leaf) node of the binary tree, one flag is signaled to indicate which partition type (i.e., horizontal or vertical) is used, where in this example, 0 indicates a horizontal partition and 1 indicates a vertical partition. In the case of a quadtree partition, there is no need to indicate the partition type, as the quadtree node divides the block horizontally and vertically into four subblocks of equal size. Thus, the video encoder 200 can encode syntax elements (such as partition information) for the domain tree level (i.e., solid lines) of the QTBT structure 130 and syntax elements (such as partition information) for the predictive tree level (i.e., dashed lines) of the QTBT structure 130, and the video decoder 300 can decode those syntax elements. The video encoder 200 can encode video data such as prediction data and transformation data for CUs represented by terminal leaf nodes of the QTBT structure 130, and the video decoder 300 can decode that video data.

[0073] In general, the CTU132 in Figure 2B can be associated with parameters that define the size of the blocks corresponding to the nodes of the QTBT structure 130 at the first and second levels. These parameters may include the CTU size (representing the size of the CTU132 in the sample), the minimum quadtree size (MinQTSize, representing the minimum allowed quadtree leaf node size), the maximum binary tree size (MaxBTSize, representing the maximum allowed binary tree root node size), the maximum binary tree depth (MaxBTDepth, representing the maximum allowed binary tree depth), and the minimum binary tree size (MinBTSize, representing the minimum allowed binary tree leaf node size).

[0074] The root node of a QTBT structure corresponding to a CTU may have four child nodes at the first level of the QTBT structure, each of which may be subdivided according to a quadruple tree partition. That is, a node at the first level is either a leaf node (without child nodes) or has four child nodes. An example of QTBT structure 130 represents a node that includes a parent node and child nodes with solid lines for branching. If the nodes at the first level are not larger than the maximum allowable binary tree root node size (MaxBTSize), these nodes may be further subdivided by their respective binary trees. Binary tree partitioning of a single node may be repeated until the resulting nodes reach the minimum allowable binary tree leaf node size (MinBTSize) or the maximum allowable binary tree depth (MaxBTDepth). An example of QTBT structure 130 represents a node that has dashed lines for branching. A leaf node in a binary tree is called a coding unit (CU), and without further distinction, coding units (CUs) are used for prediction (e.g., intra-picture prediction or inter-picture prediction) and transformation. As described above, CUs are sometimes also called "video blocks" or "blocks".

[0075] In one example of a QTBT partitioned structure, the CTU size is set to 128×128 (a chroma sample and two corresponding 64×64 chroma samples), MinQTSize is set to 16×16, MaxBTSize is set to 64×64, MinBTSize (for both width and height) is set to 4, and MaxBTDepth is set to 4. To generate a quadtree leaf node, the quadtree partition is first applied to the CTU. The quadtree leaf node can have sizes ranging from 16×16 (i.e., MinQTSize) to 128×128 (i.e., CTU size). If the quadtree leaf node is 128×128, the size exceeds MaxBTSize (i.e., 64×64 in this example), so the quadtree leaf node is not further partitioned by a binary tree. Otherwise, the quadtree leaf node may be further partitioned by a binary tree. Therefore, a quad tree leaf node is also the root node of a binary tree and has a binary tree depth of 0. When the binary tree depth reaches MaxBTDepth (4 in this example), no further partitioning is allowed. A binary tree node with a width equal to MinBTSize (4 in this example) suggests that no further vertical partitioning (i.e., partitioning by width) is allowed for that binary tree node. Similarly, a binary tree node with a height equal to MinBTSize suggests that no further horizontal partitioning (i.e., partitioning by height) is allowed for that binary tree node. As mentioned above, a leaf node of a binary tree is called a CU and is further processed according to prediction and transformation without further partitioning.

[0076] Figure 3 is a block diagram showing an exemplary video encoder 200 capable of performing the techniques of this disclosure. Figure 3 is provided for illustrative purposes and should not be considered a limitation of the techniques that are more broadly illustrated and described in this disclosure. For illustrative purposes, this disclosure describes the video encoder 200 in the context of video coding standards such as the ITU-T H.265 / HEVC video coding standard and the VVC video coding standard under development. However, the techniques of this disclosure are not limited to these video coding standards and are generally applicable to other video coding and decoding standards.

[0077] In the example shown in Figure 3, 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, mode selection unit 202, residual generation unit 204, conversion processing unit 206, quantization unit 208, inverse quantization unit 210, inverse conversion processing unit 212, reconstruction unit 214, filter unit 216, DPB 218, and entropy coding unit 220 may be implemented in one or more processors or processing circuits. For example, the units of the video encoder 200 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 encoder 200 may include additional or alternative processors or processing circuits to perform these and other functions.

[0078] The video data memory 230 can store video data to be encoded by the components of the video encoder 200. The video encoder 200 can receive video data stored in the video data memory 230 from, for example, a video source 104 (Figure 1). The DPB 218 can 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 DPB 218 can be formed by any of various memory devices, such as dynamic random access memory (DRAM) including synchronous DRAM (SDRAM), magnetoresistive RAM (MRAM), resistive RAM (RRAM), or other types of memory devices. The video data memory 230 and DPB 218 can 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 it may be off-chip relative to those components.

[0079] In this disclosure, references to the video data memory 230 should not be interpreted as being limited to internal memory of the video encoder 200, or external memory of the video encoder 200, unless otherwise specifically described. Rather, references to the video data memory 230 should be understood as reference memory that stores video data received by the video encoder 200 for encoding (e.g., video data for the current block to be encoded). Memory 106 in Figure 1 may also provide temporary storage for outputs from various units of the video encoder 200.

[0080] The various units in Figure 3 are illustrated 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 for the operations they may perform. Programmable circuits refer to circuits that can be programmed to perform a variety of tasks and offer flexibility in the operations they may perform. For example, a programmable circuit may execute software or firmware that operates the programmable circuit in a manner defined by software or firmware instructions. Fixed-function circuits may execute software instructions (e.g., 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 units may be different circuit blocks (fixed-function or programmable), and in some examples, one or more units may be integrated circuits.

[0081] The video encoder 200 may include a programmable core formed from an arithmetic logic unit (ALU), an elementary function unit (EFU), digital circuits, analog circuits, and / or programmable circuits. In an example where the operation of the video encoder 200 is performed 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.

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

[0083] 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 palette unit, an intra-block copy unit (which may be part of the motion estimation unit 222 and / or the motion compensation unit 224), an affine unit, a linear model (LM) unit, and the like.

[0084] The mode selection unit 202 generally coordinates multiple coding paths to test combinations of coding parameters and the resulting rate distortion values ​​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, and the quantization parameters for the residual data of the CU. The mode selection unit 202 may ultimately select a combination of coding parameters that has a better rate distortion value than other tested combinations.

[0085] 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 picture's CTUs according to a tree structure such as the HEVC QTBT 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 the tree structure. Such CUs are sometimes commonly referred to as "video blocks" or "blocks".

[0086] 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 for 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 exactly matching reference blocks in one or more reference pictures (e.g., one or more previously coded pictures stored in DPB 218). Specifically, the motion estimation unit 222 may calculate a value representing how similar a 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 blocks under consideration. The motion estimation unit 222 can identify the reference block with the lowest value resulting from these calculations, which indicates the reference block that most closely matches the current block.

[0087] 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 the current block in the current picture. The motion estimation unit 222 may then provide the motion vectors to the motion compensation unit 224. For example, in the case of unidirectional interpretation, the motion estimation unit 222 may provide a single motion vector, but in the case of 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 the reference blocks. As another example, if the motion vectors have fractional sample accuracy, the motion compensation unit 224 may interpolate values ​​for the predicted blocks according to one or more interpolation filters. Furthermore, in the case of bidirectional interpretation, the motion compensation unit 224 may extract data for the two reference blocks identified by each motion vector and synthesize the extracted data, for example, by sample-wise averaging or weighted averaging.

[0088] As another example, in the case of 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 generally generate a prediction block by mathematically synthesizing the values ​​of adjacent samples and populating these calculated values ​​in a defined direction across the current block. As another example, in DC mode, the intra-prediction unit 226 may calculate the average of adjacent samples for the current block and generate a prediction block in which each sample of the prediction block should include this resulting average.

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

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

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

[0092] In some examples, such as intra-block copy mode coding, affine mode coding, and other video coding techniques like linear model (LM) mode coding, the mode selection unit 202 generates a predicted block for the current block being coded via the respective unit associated with the coding technique. In some examples, such as palette mode coding, the mode selection unit 202 does not need to generate a predicted block; instead, it may generate syntax elements indicating how to reconstruct the block 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.

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

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

[0095] The quantization unit 208 can quantize the transformation coefficients in the transformation coefficient block to produce a quantized transformation coefficient block. The quantization unit 208 can quantize the transformation coefficients of the transformation coefficient block according to the quantization parameter (QP) value associated with the current block. The video encoder 200 can adjust the degree of quantization applied to the transformation coefficient 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 generated by the transformation processing unit 206.

[0096] The inverse quantization unit 210 and the inverse transformation processing unit 212 can reconstruct the residual block from the transformed coefficient block by applying inverse quantization and inverse transformation, respectively. The reconstruction unit 214 can generate a reconstructed block corresponding to the current block (which may be with some distortion) based on the reconstructed residual block and the predicted block generated by the mode selection unit 202. For example, the reconstruction unit 214 can generate a reconstructed block by adding a sample from the reconstructed residual block to a corresponding sample from the predicted block generated by the mode selection unit 202.

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

[0098] The video encoder 200 stores the reconstructed blocks in the DPB 218. For example, in cases where the operation of the filter unit 216 is not required, the reconstruction unit 214 may store the reconstructed blocks in the DPB 218. In cases where the operation of the filter unit 216 is required, the filter unit 216 may store the filtered and 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 possibly filtered) blocks from the DPB 218 to interpret blocks of the picture to be encoded later. In addition, 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.

[0099] In general, 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.

[0100] According to the technique of the present disclosure, the entropy coding unit 220 may be configured to use a Rice parameter to binarize the absolute value of the residual level value of the current quantized transformation coefficient. The entropy coding unit 220 may first determine the Rice parameter by determining the local sum (locSumAbs) of the absolute values ​​of transformation coefficients adjacent to the current quantized transformation coefficient. Such adjacent transformation coefficients may be as shown in the example in Figure 5 below. That is, adjacent transformation coefficients may include a transformation coefficient adjacent to the right, a transformation coefficient two positions to the right, a transformation coefficient adjacent to the lower right, a transformation coefficient adjacent to the lower, and a transformation coefficient two positions below.

[0101] After calculating the locSumAbs value, the entropy coding unit 220 may derive a shift value from the locSumAbs value. For example, the entropy coding unit 220 may calculate the shift value according to "shift = ((Bitdepth - b) > 0) && (localSumAbs - baseLevel * 5) >= T ? Floor(Log2(a*(Bitdepth - b))) : 0". In this example, Bitdepth represents the bit depth of the video data, a is an integer power of 2, b represents the operation bit depth, and T represents the threshold.

[0102] After determining the shift value, the entropy coding unit 220 may use the shift value to normalize the calculated locSumAbs value. For example, the entropy coding unit 220 may normalize the locSumAbs value according to "localSumAbs = (shift == 0) ? localSumAbs : (localSumAbs + (1 << (shift -1) )) >> shift". In this example, "<<" and ">>" represent bitwise left and right shift operators. In both of the above examples, the "A ? B : C" function returns value B if A is true, and value C if A is false. The entropy coding unit 220 may also clip the normalized locSumAbs value according to "locSumAbs = Clip3( 0, 31, locSumAbs - baseLevel * 5 )".

[0103] After calculating the normalized locSumAbs value, the entropy coding unit 220 may use the normalized locSumAbs value as input to perform a lookup in a lookup table to determine the rice parameter (e.g., cRiceParam). The lookup table may be the same as the current one of the VVC and can be reproduced below as Table 1. The entropy coding unit 220 may use the determined rice parameter to binarize the absolute remainder of the current transformation coefficient and then entropy code the binarized absolute remainder.

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

[0105] The behavior described above is described in relation to blocks. Such descriptions should be understood as behavior for rumacoding blocks and / or chromacoding blocks. As described above, in some examples, the rumacoding block and chromacoding block are the ruma and chroma components of the CU. In some examples, the rumacoding block and chromacoding block are the ruma and chroma components of the PU.

[0106] In some cases, actions performed for a rumacoding block do not need to be repeated for a chromacoding block. For example, actions to identify the motion vector (MV) and reference picture for a rumacoding block do not need to be repeated to identify the MV and reference picture for a chromacoding block. Rather, the MV for the rumacoding block may be scaled to determine the MV for the chromacoding block, 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.

[0107] Thus, the video encoder 200 represents an example of a device for binarizing video data, comprising a memory configured to store video data, and one or more processors implemented in the circuit and configured to calculate a local sum (locSumAbs value) of the absolute values ​​of the coefficients adjacent to the current coefficient in the current block of video data, derive a shift value from the locSumAbs value, normalize the locSumAbs value using the shift value, determine a rice parameter using the normalized locSumAbs value, and binarize or inversely binarize the current coefficient using the rice parameter.

[0108] Figure 4 is a block diagram showing an exemplary video decoder 300 capable of performing the techniques of this disclosure. Figure 4 is provided for illustrative purposes and is not intended to limit the techniques that are broadly illustrated and described in this disclosure. For illustrative purposes, this disclosure describes a video decoder 300 using VVC and HEVC (ITU-T H.265) techniques. However, the techniques of this disclosure may be performed by video coding devices configured according to other video coding standards.

[0109] In the example in Figure 4, 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, entropy decoding unit 302, prediction processing unit 304, inverse quantization unit 306, inverse transformation processing unit 308, reconstruction unit 310, filter unit 312, and 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.

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

[0111] 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 retrieved, 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 encoded picture, such as temporary data representing outputs 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, such as dynamic random access memory (DRAM) including synchronous DRAM (SDRAM), magnetoresistive RAM (MRAM), resistive RAM (RRAM), or other types of memory devices. The CPU 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 together with the other components of the video decoder 300, or it may be off-chip relative to those components.

[0112] As an addition or alternative, in some examples, the video decoder 300 may retrieve coded video data from memory 120 (Figure 1). That is, memory 120 may store data as described above with respect to the CPB memory 320. 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.

[0113] The various units shown in Figure 4 are illustrated 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. Similar to Figure 3, fixed-function circuits refer to circuits that provide a specific function and are preset for the operations they may perform. Programmable circuits refer to circuits that can be programmed to perform various tasks and offer flexibility in the operations they may perform. For example, a programmable circuit may execute software or firmware that operates the programmable circuit in a manner defined by software or firmware instructions. Fixed-function circuits may execute software instructions (e.g., 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 units may be different circuit blocks (fixed-function or programmable), and in some examples, one or more units may be integrated circuits.

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

[0115] The entropy decoding unit 302 can receive video data encoded from the CPB and reconstruct the syntax elements by entropy decoding the video data. 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 the decoded video data based on the syntax elements extracted from the bitstream.

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

[0117] The entropy decoding unit 302 can entropy decode the quantized transformation coefficients of a quantized transformation coefficient block, as well as syntax elements that define transformation information such as quantization parameters (QP) and / or transformation mode indications. According to the technique of the present disclosure, the entropy decoding unit 302 may be configured to use a Rice parameter to entropy decode the absolute value of the residual level value of the current quantized transformation coefficient, and then inversely binarize it.

[0118] The entropy decoding unit 302 can initially determine the Rice parameter by determining the local sum (locSumAbs) of the absolute values ​​of the transformation coefficients adjacent to the currently quantized transformation coefficient. Such adjacent transformation coefficients may be those shown in the example in Figure 5 below. That is, adjacent transformation coefficients may include the transformation coefficient adjacent to the right, the transformation coefficient two positions to the right, the transformation coefficient adjacent to the lower right, the transformation coefficient adjacent to the lower, and the transformation coefficient two positions below.

[0119] After calculating the locSumAbs value, the entropy decoding unit 302 may derive a shift value from the locSumAbs value. For example, the entropy decoding unit 302 may calculate the shift value according to "shift = ((Bitdepth - b) > 0) && (localSumAbs - baseLevel * 5) >= T ? Floor(Log2(a*(Bitdepth - b))) : 0". In this example, Bitdepth represents the bit depth of the video data, a is an integer power of 2, b represents the operation bit depth, and T represents the threshold.

[0120] After determining the shift value, the entropy decoding unit 302 may use the shift value to normalize the calculated locSumAbs value. For example, the entropy decoding unit 302 may normalize the locSumAbs value according to "localSumAbs = (shift == 0) ? localSumAbs : (localSumAbs + (1 << (shift -1) )) >> shift". In this example, "<<" and ">>" represent bitwise left and right shift operators. In both of the above examples, the "A ? B : C" function returns value B if A is true, and value C if A is false. The entropy decoding unit 302 may also clip the normalized locSumAbs value according to "locSumAbs = Clip3( 0, 31, locSumAbs - baseLevel * 5 )".

[0121] After calculating the normalized locSumAbs value, the entropy decoding unit 302 may use the normalized locSumAbs value as input to perform a lookup in a lookup table to determine the rice parameter (e.g., cRiceParam). The lookup table may be the same as the current one in the VVC and can be reproduced below as Table 1. The entropy decoding unit 302 may use the determined rice parameter to inverse-binarize the absolute remainder of the current transformation coefficients.

[0122] 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, for example, perform 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.

[0123] After the inverse quantization unit 306 has formed a transformation coefficient block, the inverse transformation processing unit 308 may apply one or more inverse transformations to the transformation coefficient block to generate a 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 transform (KLT), an inverse rotation transform, an inverse direction transform, or another inverse transformation to the transformation coefficient block.

[0124] 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 a prediction block. 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 can generally perform the interprediction process in substantially the same manner as described with respect to the motion compensation unit 224 (Figure 3).

[0125] 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. Again, the intra-prediction unit 318 may generally perform the intra-prediction process in substantially the same manner as described with respect to the intra-prediction unit 226 (Figure 3). The intra-prediction unit 318 may retrieve adjacent sample data for the current block from the DPB 314.

[0126] The reconstruction unit 310 may reconstruct the current block using the predicted block and the residual block. For example, the reconstruction unit 310 may reconstruct the current block by adding a sample from the residual block to the corresponding sample from the predicted block.

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

[0128] 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 refined, filtered, and reconstructed blocks in the DPB 314. As described above, the DPB 314 may provide the prediction processing unit 304 with reference information such as the current picture for intra-prediction and samples of previously decoded pictures for subsequent motion compensation. Furthermore, the video decoder 300 may output the decoded pictures from the DPB 314 for later presentation on a display device such as the display device 118 in Figure 1.

[0129] Thus, the video decoder 300 represents an example of a device for binarizing video data, comprising a memory configured to store video data, and one or more processors implemented in the circuit and configured to calculate a local sum (locSumAbs value) of the absolute values ​​of the coefficients adjacent to the current coefficient of the current block of video data, derive a shift value from the locSumAbs value, normalize the locSumAbs value using the shift value, determine a rice parameter using the normalized locSumAbs value, and binarize or inversely binarize the current coefficient using the rice parameter.

[0130] Figure 5 is a conceptual diagram showing an exemplary set of adjacent coefficients that may be used when calculating the local sum of adjacent absolute values ​​(localSumAbs) for the current coefficient. The video encoder 200 and video decoder 300 may use the local sum of adjacent absolute values ​​for the current coefficient to determine the Rice parameter. For example, in VVC, the Rice parameter for residual coding (RRC) is typically derived using a lookup table that takes into account the coefficient values ​​of adjacent transformation coefficients in a template. A template of adjacent coefficients is presented in Figure 5.

[0131] First, the video encoder 200 and video decoder 300 can calculate locSumAbs, which is the absolute sum of the five available adjacent coefficients in the template. Then, the video encoder 200 and video decoder 300 can normalize locSumAbs (subtract and clip) as follows: locSumAbs = Clip3( 0, 31, locSumAbs - baseLevel * 5 )

[0132] The video encoder 200 and video decoder 300 can derive the rice parameter value (e.g., cRiceParam) using the lookup table in Table 1 below.

[0133] [Table 1]

[0134] Figure 6 is a flowchart illustrating an exemplary method for encoding the current block using the technique of this disclosure. The current block may include the current CU. While the video encoder 200 (Figures 1 and 3) is described, it should be understood that other devices may be configured to perform a similar method to that shown in Figure 6.

[0135] 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 and quantize the coefficients of the residual block (354). The video encoder 200 may then scan the quantized transformed coefficients of the residual block (356). During or following the scan, the video encoder 200 may entropy encode the coefficients (358). For example, the video encoder 200 may encode the coefficients using CAVLC or CABAC. The video encoder 200 may then output the entropy encoded data of the block (360).

[0136] Figure 7 is a flowchart illustrating an exemplary method for decoding the current block using the technique of this disclosure. The current block may include the current CU. While the video decoder 300 (Figures 1 and 4) is described, it should be understood that other devices may be configured to perform a similar method to that shown in Figure 7.

[0137] The video decoder 300 may receive entropy-encoded data for the current block, such as entropy-encoded prediction information and entropy-encoded data of the 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 coefficients of the residual block (372). The video decoder 300 may predict the current block, for example, using an intra-prediction mode or inter-prediction mode as indicated by the prediction information for the current block, in order to compute a prediction block for the current block (374). The video decoder 300 may then back-scan the reconstructed coefficients to create a block of quantized transformation coefficients (376). The video decoder 300 may then inverse-quantize and inverse-transform the quantized transformation coefficients to generate a residual block (378). The video decoder 300 may finally decode the current block by combining the prediction block and the residual block (380).

[0138] Figure 8 is a flowchart illustrating an exemplary method for binarizing video data using the technique of the present disclosure. The method of Figure 8 is described with respect to the video encoder 200 of Figures 1 and 3. In other examples, other devices may be configured to perform these or similar techniques. Furthermore, the method of Figure 8 may generally correspond to a portion of step 358 of Figure 6.

[0139] First, the video encoder 200 may receive the current conversion coefficient. The current conversion coefficient may have an absolute value greater than 2. The video encoder 200 may calculate a local sum of absolute values ​​(locSumAbs value) with respect to the current coefficient from coefficients adjacent to the current coefficient (380). For example, as shown in the example in Figure 5, the video encoder 200 may add the absolute values ​​of the conversion coefficients immediately to the right of the current conversion coefficient, two positions to the right of the current conversion coefficient, to the lower right of the current conversion coefficient, immediately below the current conversion coefficient, and two positions below the current conversion coefficient.

[0140] Next, the video encoder 200 can calculate a shift value from the locSumAbs value to the current coefficient (382). For example, the video encoder 200 can calculate a shift value according to the formula "shift = ((Bitdepth - b) > 0) && (localSumAbs - baseLevel * 5) >= T ? Floor(Log2(a*(Bitdepth - b))) : 0". As another example, the video encoder 200 can calculate two shift values, shift and shift1, according to the formulas "shift = ((Bitdepth - b) > 0) && (localSumAbs - baseLevel * 5) >= T ? Floor(Log2(a*(Bitdepth - b))) : 0" and "shift1 = (Bitdepth - b) > 0) && (localSumAbs - baseLevel * 5) >= T ? Floor(Log2(a*(Bitdepth - b))) : 0". As another example, video encoder 200 may calculate the shift value according to the formula "shift = (locSumAbs * scl) >= T ? FloorLog2((locSumAbs * scl) >> N) : 0".

[0141] Next, the video encoder 200 may normalize the locSumAbs value using the shift value (384). For example, the video encoder 200 may normalize the locSumAbs value according to "localSumAbs = (shift == 0) ? localSumAbs : (localSumAbs + (1 << (shift -1) )) >> shift". As another example, if two shift values ​​(shift and shift1) are used, the video encoder 200 may normalize locSumAbs according to "localSumAbs = (shift == 0) ? localSumAbs : (localSumAbs + (1 << (shift -1) )) >> shift" and "localSumAbs = (shift1 == 0) ? localSumAbs : (localSumAbs + (1 << (shift1 -1) )) >> shift1". As yet another example, the video encoder 200 may normalize locSumAbs according to "locSumAbs = locSumAbs >> shift".

[0142] Next, the video encoder 200 may determine the Rice parameters from the normalized locSumAbs value (386). For example, the video encoder 200 may determine the Rice parameters using Table 1 above.

[0143] Next, the video encoder 200 may binarize the conversion coefficients using the determined Rice parameters (388). Finally, the video encoder 200 may entropy encode the binarized conversion coefficients (390).

[0144] Thus, the method in Figure 8 represents an example of a method that includes the steps of: calculating a local sum of the absolute values ​​of the coefficients adjacent to the current coefficient in the current block of video data (locSumAbs value); deriving a shift value from the locSumAbs value; normalizing the locSumAbs value using the shift value; determining the rice parameter using the normalized locSumAbs value; and binarizing or inversely binarizing the current coefficient using the rice parameter.

[0145] Figure 9 is a flowchart illustrating an exemplary method for de-binarizing video data using the technique of this disclosure.

[0146] First, the video decoder 300 can receive the binarized, entropy-encoded data of the current transformation coefficient. Specifically, the video decoder 300 can entropy-decode the syntax elements of the entropy-encoded transformation coefficient, which include a significance flag, a greater than 1 flag, and a greater than 2 flag indicating that the transformation coefficient has a value greater than 2. Thus, the video decoder 300 can determine that the remainder of the transformation coefficient should be decoded. Thus, the video decoder 300 can first entropy-decode the binarized transformation coefficient (i.e., the remainder of the binarized transformation coefficient) (400).

[0147] Next, the video decoder 300 can calculate a local sum of absolute values ​​(locSumAbs value) of the coefficients adjacent to the current coefficient with respect to the current coefficient (402). For example, as shown in the example in Figure 5, the video decoder 300 can add the absolute values ​​of the transformation coefficients immediately to the right of the current transformation coefficient, two positions to the right of the current transformation coefficient, to the lower right of the current transformation coefficient, immediately below the current transformation coefficient, and two positions below the current transformation coefficient.

[0148] Next, the video decoder 300 can calculate a shift value from the locSumAbs value to the current coefficient (404). For example, the video decoder 300 can calculate a shift value according to the formula "shift = ((Bitdepth - b) > 0) && (localSumAbs - baseLevel * 5) >= T ? Floor(Log2(a*(Bitdepth - b))) : 0". As another example, the video decoder 300 can calculate two shift values, shift and shift1, according to the formulas "shift = ((Bitdepth - b) > 0) && (localSumAbs - baseLevel * 5) >= T ? Floor(Log2(a*(Bitdepth - b))) : 0" and "shift1 = (Bitdepth - b) > 0) && (localSumAbs - baseLevel * 5) >= T ? Floor(Log2(a*(Bitdepth - b))) : 0". As another example, the video decoder 300 may calculate the shift value according to the formula "shift = (locSumAbs * scl) >= T ? FloorLog2((locSumAbs * scl) >> N) : 0".

[0149] Next, the video decoder 300 may normalize the locSumAbs value using the shift value (406). For example, the video decoder 300 may normalize the locSumAbs value according to "localSumAbs = (shift == 0) ? localSumAbs : (localSumAbs + (1 << (shift -1) )) >> shift". As another example, if two shift values ​​(shift and shift1) are used, the video decoder 300 may normalize locSumAbs according to "localSumAbs = (shift == 0) ? localSumAbs : (localSumAbs + (1 << (shift -1) )) >> shift" and "localSumAbs = (shift1 == 0) ? localSumAbs : (localSumAbs + (1 << (shift1 -1) )) >> shift1". As yet another example, the video decoder 300 may normalize locSumAbs according to "locSumAbs = locSumAbs >> shift".

[0150] Next, the video decoder 300 may determine the Rice parameters from the normalized locSumAbs values ​​(408). For example, the video decoder 300 may determine the Rice parameters using Table 1 above. Then, the video decoder 300 may inversely binarize the conversion coefficients (specifically, the remainders) using the determined Rice parameters (410).

[0151] Thus, the method in Figure 9 represents an example of a method that includes the steps of: calculating a local sum of the absolute values ​​of the coefficients adjacent to the current coefficient in the current block of video data (locSumAbs value); deriving a shift value from the locSumAbs value; normalizing the locSumAbs value using the shift value; determining the rice parameter using the normalized locSumAbs value; and binarizing or inversely binarizing the current coefficient using the rice parameter.

[0152] The following clauses summarize some exemplary techniques of this disclosure.

[0153] Clause 1: A method for decoding video data, comprising the steps of deriving Rice parameters in accordance with any of the techniques of the Disclosure, and decoding video data using the Rice parameters.

[0154] Clause 2: The method of Clause 1, wherein the step of deriving the Rice parameter includes the step of determining the local sum of absolute values ​​of coefficients adjacent to the current coefficient, and the step of scaling the local sum of absolute values ​​using a scaling value.

[0155] Clause 3: The method of Clause 2, further comprising the step of determining a scaling value according to one or more of the following: input bit depth, predefined operation bit depth, local activity of conversion coefficients, block size, or syntax elements signaled in a bitstream containing video data.

[0156] Clause 4: Any method of Clauses 2 and 3, further comprising the step of clipping the local sum of absolute values.

[0157] Clause 5: Any method of Clauses 2-4, further including the step of normalizing the local sum of absolute values.

[0158] Clause 6: The steps for deriving the Rice parameters are as follows:

[0159] [Table 2]

[0160] Any method of clauses 2 to 5, including the step of deriving the rice parameter (cRiceParam) from the local sum of absolute values ​​(locSumAbs) according to the formula.

[0161] Clause 7: Any method of Clauses 2-6, wherein the step of determining the local sum of absolute values ​​includes the step of calculating localSumAbs = (shift == 0) ? localSumAbs : (localSumAbs + (1 << (shift -1) )) >> shift.

[0162] Clause 8: The method of Clause 7, further including the step of calculating the value of shift as shift = (Bitdepth - b) > 0 ? Floor(Log2(a*(Bitdepth - b))) : 0.

[0163] Clause 9: The method of Clause 8, where Bitdepth specifies the bit depth of the video data, b specifies the calculation bit depth, a is set to be equal to an integer power of 2, and c is set according to the calculated shift value.

[0164] Clause 10: The method of Clause 7, further including the step of calculating the value of shift as shift = (Bitdepth - b) > 0) && (localSumAbs - baseLevel * 5) >= T ? Floor(Log2(a*(Bitdepth - b))) : 0.

[0165] Clause 11: The method of Clause 10, wherein T is a predefined threshold.

[0166] Clause 12: Any method of Clauses 2-6, wherein the step of determining the local sum of absolute values ​​includes the steps of calculating localSumAbs = (shift == 0) ? localSumAbs : (localSumAbs + (1 << (shift -1) )) >> shift, and localSumAbs = (shift1 == 0) ? localSumAbs : (localSumAbs + (1 << (shift1 -1) )) >> shift1.

[0167] Clause 13: The method of Clause 15, further including the step of calculating the values ​​of shift and shift1 as shift = (Bitdepth - b) > 0) && (localSumAbs - baseLevel * 5) >= T ? Floor(Log2(a*(Bitdepth - b))) : 0, and shift1 = (Bitdepth - b) > 0) && (localSumAbs - baseLevel * 5) >= T ? Floor(Log2(a*(Bitdepth - b))) : 0.

[0168] Clause 14: The method of Clause 13, where T is a threshold, Bitdepth specifies the bit depth of the video data, b specifies the operation bit depth, and a is set to be equal to an integer power of 2.

[0169] Clause 15: Any method of Clauses 2-6, wherein the step of determining the local sum of absolute values ​​includes the steps of calculating shift = (locSumAbs * scl) >= T ? FloorLog2((locSumAbs * scl) >> N) : 0, locSumAbs = locSumAbs >> shift, and locSumAbs = Clip3( 0, 31, locSumAbs - baseLevel * 5 ).

[0170] Clause 16: The method of Clause 15, where T is the threshold value, scl is the scaling value, and N is the number of bits.

[0171] Clause 17: The method of Clause 16, further comprising the step of determining values ​​for one or more of T, scl, and N according to the bit depth of a bitstream containing video data.

[0172] Clause 18: The method of Clause 16, further comprising the step of determining values ​​for one or more of T, scl, and N from signaled data in a bitstream containing video data.

[0173] Clause 19: The method of Clause 18, wherein the signaled data includes one or more data from among sequence parameter sets (SPS), picture parameter sets (PPS), adaptive parameter sets (APS), or slice headers.

[0174] Clause 20: The method of Clause 16, further comprising the steps of determining a value of 8 for T, a value of 3 for N, and scl = floorLog2(bitdepth - 10), wherein bitdepth has a value representing the bit depth of the bitstream containing the video data.

[0175] Clause 21: The method of Clause 16, further comprising the step of determining a predetermined value for one or more of T, scl, and N.

[0176] Clause 22: Any method of Clauses 7-20, further comprising the step of deriving a temporary rice parameter value using the value of localSumAbs, and then calculating the rice parameter as the sum of the temporary rice parameter value and the variable c.

[0177] Clause 23: The method of Clause 21, further comprising the step of determining the value of c as equal to the value of shift.

[0178] Clause 24: The method of Clause 21, further comprising the step of deriving the value of c from the value of shift.

[0179] Clause 25: Any method of Clauses 1-23, further comprising the step of encoding the video data before decoding the video data.

[0180] Clause 26: A device for decoding video data, comprising one or more means configured to perform any of the methods described in Clauses 1 to 25.

[0181] Clause 27: The device of Clause 26, wherein one or more means comprises one or more processors implemented in a circuit.

[0182] Clause 28: The device of Clause 26, further comprising a display configured to display decoded video data.

[0183] Clause 29: A device under Clause 26 comprising one or more of the following: a camera, a computer, a mobile device, a broadcast receiver device, or a set-top box.

[0184] Clause 30: The device of Clause 26, further comprising memory configured to store video data.

[0185] Clause 31: A computer-readable storage medium that stores instructions, when executed, causing a processor to perform any of the methods described in Clauses 1 through 25.

[0186] Clause 32: A method for binarizing video data, comprising the steps of: calculating a local sum of absolute values ​​of coefficients adjacent to the current coefficient in the current block of video data (locSumAbs value); deriving a shift value from the locSumAbs value; normalizing the locSumAbs value using the shift value; determining a rice parameter using the normalized locSumAbs value; and binarizing or inversely binarizing the current coefficient using the rice parameter.

[0187] Clause 33: The method of Clause 32, further comprising the step of using a Rice parameter to encode or decode the current coefficient using context-adaptive binary arithmetic coding (CABAC).

[0188] Clause 34: The method of Clause 32, wherein the step of normalizing the locSumAbs value includes the step of right-shifting the locSumAbs value bitwise using a shift value.

[0189] Clause 35: The method of Clause 32, further comprising the step of clipping the normalized locSumAbs value.

[0190] Clause 36: The method of Clause 32, wherein the step of determining the rice parameter includes the step of deriving the rice parameter from normalized locSumAbs values ​​according to a lookup table.

[0191] Clause 37: Lookup table

[0192] [Table 3]

[0193] The method of Clause 36, which includes and includes the rice parameter cRiceParam.

[0194] Clause 38: The method of Clause 32, wherein the steps of calculating the locSumAbs value and normalizing the locSumAbs value include the step of calculating the localSumAbs value as equal to (shift == 0) ? localSumAbs : (localSumAbs + (1 << (shift -1) )) >> shift.

[0195] Clause 39: The method of Clause 38, wherein the step of deriving the value of shift includes the step of calculating the value of shift as shift = (Bitdepth - b) > 0 ? Floor(Log2(a*(Bitdepth - b))) : 0.

[0196] Clause 40: The method of Clause 39, where Bitdepth specifies the bit depth of the video data, b specifies the calculation bit depth, a is set to be equal to an integer power of 2, and c is set according to the calculated shift value.

[0197] Clause 41: The method of Clause 38, wherein the step of deriving the shift value includes the step of calculating the value of shift as shift = ((Bitdepth - b) > 0) && (localSumAbs - baseLevel * 5) >= T ? Floor(Log2(a*(Bitdepth - b))) : 0.

[0198] Clause 42: The method of Clause 41, wherein T is a predefined threshold.

[0199] Clause 43: The method of Clause 32, wherein the step of deriving a shift value further includes the step of deriving a shift value according to one or more of the input bit depth, a predefined operation bit depth, local activity of the conversion coefficients, block size, or syntax elements signaled in a bitstream containing video data.

[0200] Clause 44: The method of Clause 32, wherein the steps of calculating the locSumAbs value and normalizing the locSumAbs value include the steps of calculating localSumAbs = (shift == 0) ? localSumAbs : (localSumAbs + (1 << (shift -1) )) >> shift, and localSumAbs = (shift1 == 0) ? localSumAbs : (localSumAbs + (1 << (shift1 -1) )) >> shift1.

[0201] Clause 45: The method of Clause 44, wherein the step of deriving the shift value includes the step of calculating the values ​​of shift and shift1 as shift = ((Bitdepth - b) > 0) && (localSumAbs - baseLevel * 5) >= T ? Floor(Log2(a*(Bitdepth - b))) : 0, and shift1 = ((Bitdepth - b) > 0) && (localSumAbs - baseLevel * 5) >= T ? Floor(Log2(a*(Bitdepth - b))) : 0.

[0202] Clause 46: The method of Clause 45, where T is a threshold, Bitdepth specifies the bit depth of the video data, b specifies the operation bit depth, and a is set to be equal to an integer power of 2.

[0203] Clause 47: The method of Clause 32, wherein the steps of calculating the locSumAbs value, deriving the shift value, and normalizing the locSumAbs value include the steps of calculating shift = (locSumAbs * scl) >= T ? FloorLog2((locSumAbs * scl) >> N) : 0, locSumAbs = locSumAbs >> shift, and locSumAbs = Clip3( 0, 31, locSumAbs - baseLevel * 5 ).

[0204] Clause 48: The method of Clause 47, where T is the threshold value, scl is the scaling value, and N is the number of bits.

[0205] Clause 49: The method of Clause 48, further comprising the step of determining a value for one or more of T, scl, and N according to the bit depth of a bitstream containing video data.

[0206] Clause 50: The method of Clause 48, further comprising the step of determining values ​​for one or more of T, scl, and N from signaled data in a bitstream containing video data.

[0207] Clause 51: The method of Clause 50, wherein the signaled data includes one or more data from among sequence parameter sets (SPS), picture parameter sets (PPS), adaptive parameter sets (APS), or slice headers.

[0208] Clause 52: The method of Clause 48, further comprising the steps of determining a value of 8 for T, a value of 3 for N, and scl = floorLog2(bitdepth - 10), wherein bitdepth has a value representing the bit depth of the bitstream containing the video data.

[0209] Clause 53: The method of Clause 48, further comprising the step of determining a predetermined value for one or more of T, scl, and N.

[0210] Clause 54: The method of Clause 32, further comprising the step of deriving a temporary rice parameter value using a localSumAbs value, wherein the step of determining the rice parameter comprises the step of calculating the rice parameter as the sum of a temporary rice parameter value and a variable c.

[0211] Clause 55: The method of Clause 54, further comprising the step of determining the value of c as equal to the shift value.

[0212] Clause 56: The method of Clause 54, further comprising the step of deriving the value of c from the shift value.

[0213] Clause 57: The method of Clause 32, further comprising the step of encoding or decoding video data.

[0214] Clause 58: A device for binarizing video data, comprising: a memory configured to store video data; and one or more processors implemented in a circuit and configured to calculate a local sum (locSumAbs value) of the absolute values ​​of the coefficients adjacent to the current coefficient of the current block of video data; derive a shift value from the locSumAbs value; normalize the locSumAbs value using the shift value; determine a rice parameter using the normalized locSumAbs value; and binarize or inversely binarize the current coefficient using the rice parameter.

[0215] Clause 59: A device of Clause 58 in which one or more processors are configured to encode or decode the current coefficient using context-adaptive binary arithmetic coding (CABAC).

[0216] Clause 60: A device of Clause 58 in which one or more processors are configured to right-shift the locSumAbs value bit by bit using a shift value in order to normalize the locSumAbs value.

[0217] Clause 61: The device of Clause 58, further configured with one or more processors to clip normalized locSumAbs values.

[0218] Clause 62: The device of Clause 58, wherein one or more processors are configured to derive the rice parameters from normalized locSumAbs values ​​according to a lookup table in order to determine the rice parameters.

[0219] Clause 63: Lookup table

[0220] [Table 4]

[0221] A device of Clause 62 that includes and whose rice parameter includes cRiceParam.

[0222] Clause 64: The device of Clause 58, further comprising a display configured to display decoded video data.

[0223] Clause 65: A device under Clause 58, comprising one or more of the following: a camera, a computer, a mobile device, a broadcast receiver device, or a set-top box.

[0224] Clause 66: A computer-readable storage medium storing instructions, wherein, when the instructions are executed, the processor causes the processor to: calculate a local sum of absolute values ​​of coefficients adjacent to the current coefficient in the current block of video data (locSumAbs value); derive a shift value from the locSumAbs value; normalize the locSumAbs value using the shift value; determine a rice parameter using the normalized locSumAbs value; and binarize or inversely binarize the current coefficient using the rice parameter.

[0225] Clause 67: A computer-readable storage medium of Clause 66, further comprising instructions causing a processor to encode or decode the current coefficient using context-adaptive binary arithmetic coding (CABAC).

[0226] Clause 68: A computer-readable storage medium of Clause 66, wherein the instruction for the processor to normalize the locSumAbs value includes an instruction for the processor to right-shift the locSumAbs value bit by bit using a shift value.

[0227] Clause 69: A computer-readable storage medium of Clause 66, further comprising instructions causing a processor to clip a normalized locSumAbs value.

[0228] Clause 70: A computer-readable storage medium of Clause 66, wherein instructions causing the processor to determine the rice parameter include instructions causing the processor to derive the rice parameter from a normalized locSumAbs value according to a lookup table.

[0229] Clause 71: Lookup table

[0230] [Table 5]

[0231] A computer-readable storage medium of Clause 70, which includes the Rice parameter cRiceParam.

[0232] Clause 72: A device for binarizing video data, comprising means for calculating a local sum (locSumAbs value) of absolute values ​​of coefficients adjacent to the current coefficient of the current block of video data; means for deriving a shift value from the locSumAbs value; means for normalizing the locSumAbs value using the shift value; means for determining a rice parameter using the normalized locSumAbs value; and means for binarizing or inversely binarizing the current coefficient using the rice parameter.

[0233] Clause 73: The device of Clause 72, further comprising means for context-adaptive binary arithmetic coding (CABAC) encoding or decoding the current coefficient.

[0234] Clause 74: The device of Clause 72, wherein the means for normalizing the locSumAbs value comprises means for right-shifting the locSumAbs value bitwise using a shift value.

[0235] Clause 75: The device of Clause 72, further comprising means for clipping normalized locSumAbs values.

[0236] Clause 76: The device of Clause 72, wherein the means for determining the rice parameter comprises means for deriving the rice parameter from a normalized locSumAbs value according to a lookup table.

[0237] Clause 77: Lookup table

[0238] [Table 6]

[0239] A device of Clause 76 that includes and whose rice parameter includes cRiceParam.

[0240] Clause 78: A method for binarizing video data, comprising the steps of: calculating a local sum of absolute values ​​of coefficients adjacent to the current coefficient in the current block of video data (locSumAbs value); deriving a shift value from the locSumAbs value; normalizing the locSumAbs value using the shift value; determining a rice parameter using the normalized locSumAbs value; and binarizing or inversely binarizing the current coefficient using the rice parameter.

[0241] Clause 79: The method of Clause 78, further comprising the step of encoding or decoding the current coefficient using context-adaptive binary arithmetic coding (CABAC).

[0242] Clause 80: Any method of Clauses 78 and 79, wherein the step of normalizing the locSumAbs value includes the step of right-shifting the locSumAbs value bit by bit using the shift value.

[0243] Clause 81: Any method of Clauses 78-80, further comprising the step of clipping the normalized locSumAbs value.

[0244] Clause 82: Any method of Clauses 78-81, wherein the step of determining the rice parameter includes the step of deriving the rice parameter from normalized locSumAbs values ​​according to a lookup table.

[0245] Clause 83: Lookup table

[0246]

Table 7

[0247] The method of clause 82, which includes [[ID=]], and the rice parameter includes cRiceParam.

[0248] Clause 84: Any method of clauses 78 - 83, including the steps of calculating the locSumAbs value and normalizing the locSumAbs value, where the localSumAbs value is calculated as (shift == 0)? localSumAbs : (localSumAbs + (1 << (shift - 1) )) >> shift.

[0249] Clause 85: The method of clause 84, including the step of deriving the value of shift, where the value of shift is calculated as shift = (Bitdepth - b) > 0? Floor(Log2(a*(Bitdepth - b))) : 0.

[0250] Clause 86: The method of clause 85, where Bitdepth specifies the bit depth of the video data, b specifies the arithmetic bit depth, a is set equal to an integer power of 2, and c is set according to the calculated shift value.

[0251] Clause 87: Any method of clauses 84 - 86, including the step of deriving the shift value, where the value of shift is calculated as shift = ((Bitdepth - b) > 0) && (localSumAbs - baseLevel * 5) >= T? Floor(Log2(a*(Bitdepth - b))) : 0.

[0252] Clause 88: The method of clause 87, where T is a predefined threshold.

[0253] Clause 89: The method according to any of Clauses 78 to 88, wherein the step of deriving a shift value further includes the step of deriving the shift value according to one or more of an input bit depth, a predefined arithmetic bit depth, a local activity of a conversion coefficient, a block size, or a syntax element signaled in a bitstream including video data.

[0254] Clause 90: The method according to any of Clauses 78 to 88, wherein the step of calculating a locSumAbs value and the step of normalizing the locSumAbs value include the steps of calculating localSumAbs = (shift == 0)? localSumAbs : (localSumAbs + (1 << (shift -1) )) >> shift, and localSumAbs = (shift1 == 0)? localSumAbs : (localSumAbs + (1 << (shift1 -1) )) >> shift1.

[0255] Clause 91: The method according to Clause 90, wherein the step of deriving a shift value includes the steps of calculating the values of shift and shift1 as shift = ((Bitdepth - b) > 0) && (localSumAbs - baseLevel * 5) >= T? Floor(Log2(a*(Bitdepth - b))) : 0, and shift1 = ((Bitdepth - b) > 0) && (localSumAbs - baseLevel * 5) >= T? Floor(Log2(a*(Bitdepth - b))) : 0.

[0256] Clause 92: The method according to Clause 91, wherein T is a threshold, Bitdepth specifies the bit depth of video data, b specifies the arithmetic bit depth, and a is set equal to an integer power of 2.

[0257] Clause 93: Any method of Clauses 78-92, wherein the steps of calculating the locSumAbs value, deriving the shift value, and normalizing the locSumAbs value include the steps of calculating shift = (locSumAbs * scl) >= T ? FloorLog2((locSumAbs * scl) >> N) : 0, locSumAbs = locSumAbs >> shift, and locSumAbs = Clip3( 0, 31, locSumAbs - baseLevel * 5 ).

[0258] Clause 94: The method of Clause 93, where T is the threshold value, scl is the scaling value, and N is the number of bits.

[0259] Clause 95: The method of Clause 94, further comprising the step of determining a value for one or more of T, scl, and N according to the bit depth of a bitstream containing video data.

[0260] Clause 96: The method of Clause 94, further comprising the step of determining values ​​for one or more of T, scl, and N from signaled data in a bitstream containing video data.

[0261] Clause 97: The method of Clause 96, wherein the signaled data includes one or more data from among sequence parameter sets (SPS), picture parameter sets (PPS), adaptive parameter sets (APS), or slice headers.

[0262] The method of Clause 98: the method of Clause 94, further comprising the steps of determining a value of 8 for T, a value of 3 for N, and scl = floorLog2(bitdepth - 10), wherein bitdepth has a value representing the bit depth of the bitstream containing the video data.

[0263] Clause 99: The method of Clause 94, further comprising the step of determining a predetermined value for one or more of T, scl, and N.

[0264] Clause 100: Any method of Clauses 78-99, further comprising the step of deriving a temporary rice parameter value using the localSumAbs value, wherein the step of determining the rice parameter includes the step of calculating the rice parameter as the sum of the temporary rice parameter value and the variable c.

[0265] Clause 101: The method of Clause 54, further comprising the step of determining the value of c as equal to the shift value.

[0266] Clause 102: The method of Clause 54, further comprising the step of deriving the value of c from the shift value.

[0267] Clause 103: Any method of Clauses 78-102, further comprising the step of encoding or decoding video data.

[0268] Clause 104: A device for binarizing video data, comprising: a memory configured to store video data; and one or more processors implemented in a circuit and configured to calculate a local sum of absolute values ​​(locSumAbs value) of coefficients adjacent to the current coefficient of the current block of video data; derive a shift value from the locSumAbs value; normalize the locSumAbs value using the shift value; determine a rice parameter using the normalized locSumAbs value; and binarize or inversely binarize the current coefficient using the rice parameter.

[0269] Clause 105: The device of Clause 104, wherein one or more processors are configured to encode or decode the current coefficient using context-adaptive binary arithmetic coding (CABAC).

[0270] Clause 106: A device according to either of Clauses 104 and 105, wherein one or more processors are configured to right-shift the locSumAbs value bitwise using a shift value to normalize the locSumAbs value.

[0271] Clause 107: A device according to any of Clauses 104 - 106, wherein one or more processors are further configured to clip the normalized locSumAbs value.

[0272] Clause 108: A device according to any of Clauses 104 - 107, wherein one or more processors are configured to derive a Rice parameter from the normalized locSumAbs value according to a look-up table to determine the Rice parameter.

[0273] Clause 109: The look-up table

[0274]

Table 8

[0275] includes, and the Rice parameter includes cRiceParam, a device according to Clause 108.

[0276] Clause 110: A device according to any of Clauses 104 - 109, further comprising a display configured to display the decoded video data.

[0277] Clause 111: A device according to any of Clauses 104 - 110, wherein the device comprises one or more of a camera, a computer, a mobile device, a broadcast receiver device, or a set-top box.

[0278] Clause 112: A computer-readable storage medium storing instructions, wherein, when the instructions are executed, the processor causes the processor to: calculate a local sum of absolute values ​​of coefficients adjacent to the current coefficient in the current block of video data (locSumAbs value); derive a shift value from the locSumAbs value; normalize the locSumAbs value using the shift value; determine a rice parameter using the normalized locSumAbs value; and binarize or inversely binarize the current coefficient using the rice parameter.

[0279] Clause 113: A computer-readable storage medium of Clause 112, further comprising instructions causing a processor to encode or decode the current coefficient using context-adaptive binary arithmetic coding (CABAC).

[0280] Clause 114: A computer-readable storage medium according to either Clause 112 or 113, wherein the instruction for causing the processor to normalize the locSumAbs value includes an instruction for causing the processor to right-shift the locSumAbs value bitwise using a shift value.

[0281] Clause 115: A computer-readable storage medium according to any of Clauses 112-114, further including instructions to cause the processor to clip a normalized locSumAbs value.

[0282] Clause 116: A computer-readable storage medium according to any of Clauses 112-115, wherein instructions causing the processor to determine the rice parameter include instructions causing the processor to derive the rice parameter from a normalized locSumAbs value according to a lookup table.

[0283] Clause 117: Lookup table

[0284] [Table 9]

[0285] A computer-readable storage medium as defined in Clause 116, which includes the Rice parameter cRiceParam.

[0286] Clause 118: A device for binarizing video data, comprising means for calculating a local sum (locSumAbs value) of absolute values ​​of coefficients adjacent to the current coefficient of the current block of video data; means for deriving a shift value from the locSumAbs value; means for normalizing the locSumAbs value using the shift value; means for determining a rice parameter using the normalized locSumAbs value; and means for binarizing or inversely binarizing video data using the rice parameter.

[0287] Clause 119: The device of Clause 118, further comprising means for context-adaptive binary arithmetic coding (CABAC) encoding or decoding the current coefficient.

[0288] Clause 120: A device according to either Clause 118 or 119, wherein the means for normalizing the locSumAbs value comprises means for right-shifting the locSumAbs value bitwise using a shift value.

[0289] Clause 121: Any device of Clauses 118-120, further comprising means for clipping normalized locSumAbs values.

[0290] Clause 122: Any device according to Clauses 118 to 121, wherein the means for determining the rice parameter comprises means for deriving the rice parameter from a normalized locSumAbs value according to a lookup table.

[0291] Clause 123: Lookup table

[0292] [Table 10]

[0293] A device of Clause 122 that includes a rice parameter including cRiceParam.

[0294] It should be noted that, depending on the example, some of the actions or events of any of the techniques described herein may be performed in different sequences, and may be added, merged, or excluded entirely (for example, not all actions or events described may be necessary for the practice of the technique). Furthermore, in some examples, the actions or events may be performed not sequentially, but concurrently, for example, through multithreading, interrupt handling, or multiple processors.

[0295] 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 as one or more instructions or codes on a computer-readable medium or transmitted via a computer-readable medium and executed by a hardware-based processing unit. The computer-readable medium may include computer-readable storage media corresponding to tangible media such as data storage media, or communication media including any medium that facilitates the transfer of computer programs from one location to another, for example, according to a communication protocol. Thus, the computer-readable medium may generally correspond to (1) non-transient tangible computer-readable storage media, or (2) communication media such as signals or carrier waves. The data storage medium may be any available medium that can be accessed by one or more computers or one or more processors to retrieve instructions, codes and / or data structures for implementing the techniques described herein. A computer program product may include computer-readable media.

[0296] 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 referred to as computer-readable media. 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 media. However, it should be understood that computer-readable storage media and data storage media do not include connections, carriers, signals, or other temporary media, but instead refer to non-temporary tangible storage media. The terms "disk" and "disc" as used herein include Compact Disc (CD), LaserDisc (registered trademark) (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 (disc) reproduces data optically using a laser. Any combination of the above should also be included within the scope of computer-readable media.

[0297] 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. Therefore, 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. In addition, 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. Furthermore, the techniques may be fully implemented in one or more circuits or logic elements.

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

[0299] We have described various examples. These and other examples fall within the scope of the following claims. [Explanation of Symbols]

[0300] 100 video encoding and decoding systems, systems 102 Source Device 104 Video Sources 106 memory 108 Output Interfaces 110 Computer-readable media 112 Storage Devices 114 File Server 116 Destination device 118 Display Devices 120 memory 122 Input Interfaces 130 Quadriary-Bidriary (QTBT) Structure, QTBT Structure 132 Coding Tree Unit (CTU), CTU 200 video encoders 202 Mode Selection Unit 204 Residual Generation Unit 206 Conversion Processing Unit 208 Quantization Units 210 Inverse Quantization Unit 212 Inverse Transform Processing Unit 214 Reconfiguration Unit 216 Filter Unit 218 Decoded Picture Buffer (DPB), DPB 220 Entropy Coding Units 222 Motion Estimation Unit 224 Motion Compensation Unit 226 Intra Prediction Units 230 video data memory 300 video decoders 302 Entropy Decoding Unit 304 Prediction Processing Unit 306 Inverse Quantization Unit 308 Inverse Transformation Processing Unit 310 Reconfiguration Unit 312 Filter Unit 314 Decoded Picture Buffer (DPB), DPB 316 Motion Compensation Unit 318 Intra Prediction Units 320 Encoded Picture Buffer (CPB) memory, CPB memory

Claims

1. A method performed by an encoder device, The steps include: calculating the local sum (locSumAbs value) of the absolute values ​​of the coefficients adjacent to the current coefficient in the current block of video data; A step of deriving a shift value from at least one of the bit depth of the video data and the locSumAbs value, The steps include: normalizing the locSumAbs value using the shift value to generate a normalized locSumAbs value; The steps include determining the rice parameter using the normalized locSumAbs value, The steps include: binarizing the current coefficient using the aforementioned Rice parameter; The steps of encoding the binarized current coefficients and A method that includes this.

2. The method according to claim 1, further comprising the step of encoding the current coefficient using context-adaptive binary arithmetic coding (CABAC).

3. The method according to claim 1, wherein the step of normalizing the locSumAbs value includes the step of right-shifting the locSumAbs value bitwise using the shift value to generate the normalized locSumAbs value.

4. The method according to claim 1, further comprising the step of clipping the normalized locSumAbs value.

5. The step of determining the rice parameter includes the step of deriving the rice parameter from the normalized locSumAbs value according to a lookup table, The lookup table is preferably Table 1 The method according to claim 1, wherein the rice parameter includes cRiceParam, and the method further includes the step of updating the rice parameter according to cRiceParam = cRiceParam + c, where c is based on the shift value.

6. The method according to claim 1, wherein the steps of calculating the locSumAbs value and normalizing the locSumAbs value include the step of calculating the locSumAbs value as equal to (shift == 0) ? locSumAbs : (locSumAbs + (1 << (shift -1) )) >> shift.

7. The step of deriving the shift value includes the step of calculating the shift value as shift = (Bitdepth - b) > 0 ? Floor(Log2(a*(Bitdepth - b))) : 0, The method according to claim 6, wherein Bitdepth preferably specifies the bit depth of the video data, b specifies the operation bit depth, a is set to be equal to an integer power of 2, and c is based on the shift value.

8. The step of deriving the shift value includes the step of calculating the shift value using (Bitdepth - b) > 0) && (locSumAbs - baseLevel * 5) >= T ? Floor(Log2(a*(Bitdepth - b))) : 0, The method according to claim 7, preferably in which T is a predefined threshold.

9. The method according to claim 1, wherein the step of deriving the shift value further includes the step of deriving the shift value according to one or more of the input bit depth, a predefined operation bit depth, local activity of the conversion coefficients, block size, or syntax elements signaled in the bitstream containing the video data.

10. The steps of calculating the locSumAbs value and normalizing the locSumAbs value are: locSumAbs = (shift == 0) ? locSumAbs : (locSumAbs + (1 << (shift -1) )) >> shift, and locSumAbs = (shift1 == 0) ? locSumAbs : (locSumAbs + (1 << (shift1 -1) )) >> shift1 The method according to claim 1, comprising the step of calculating.

11. The step of deriving the shift value involves the values ​​of shift and shift1. shift = ((Bitdepth - b) > 0) && (locSumAbs - baseLevel * 5) >= T ? Floor(Log2(a*(Bitdepth - b))) : 0, and shift1 = ((Bitdepth - b) > 0) && (locSumAbs - baseLevel * 5) >= T ? Floor(Log2(a*(Bitdepth - b))) : 0 This includes a step of calculating as follows: The method according to claim 10, wherein T is preferably a threshold, baseLevel represents the original value for the current coefficient, Bitdepth specifies the bit depth of the video data, b specifies the operation bit depth, and a is set to be equal to an integer power of 2.

12. The steps of calculating the locSumAbs value, deriving the shift value, and normalizing the locSumAbs value are as follows: shift = (locSumAbs * scl) >= T ? FloorLog2((locSumAbs * scl) >> N) : 0, locSumAbs = locSumAbs >> shift, locSumAbs = Clip3( 0, 31, locSumAbs - baseLevel * 5 ) The step includes calculating, The method according to claim 1, preferably wherein T is a threshold value, scl is a scaling value, and N is the number of bits.

13. The method according to claim 12, further comprising the steps of determining a value of 8 for T, a value of 3 for N, and scl = floorLog2(bitdepth - 10), wherein bitdepth is a value representing the bit depth of the bitstream containing the video data.

14. The step of determining the rice parameter further includes deriving a temporary rice parameter value using the locSumAbs value, and the step of determining the rice parameter includes calculating the rice parameter as the sum of the temporary rice parameter value and the variable c. The method according to claim 1, wherein the value of c is preferably determined to be equal to the shift value, or derived from the shift value.

15. A computer-readable storage medium storing instructions, wherein, when an instruction is executed, it causes a processor to perform the method described in any one of claims 1 to 14.

16. A method performed by a decoder device, The steps include: calculating the local sum (locSumAbs value) of the absolute values ​​of the coefficients adjacent to the current coefficient in the current block of video data; A step of deriving a shift value from at least one of the bit depth of the video data and the locSumAbs value, The steps include: normalizing the locSumAbs value using the shift value to generate a normalized locSumAbs value; The steps include determining the rice parameter using the normalized locSumAbs value, To decode the video data, the steps include: inversely binarizing the current coefficients using the Rice parameter; A method that includes this.

17. The method according to claim 16, further comprising the step of decoding the current coefficient using context-adaptive binary arithmetic coding (CABAC).

18. The method according to claim 16, wherein the step of normalizing the locSumAbs value includes the step of right-shifting the locSumAbs value bitwise using the shift value to generate the normalized locSumAbs value.

19. The method according to claim 16, further comprising the step of clipping the normalized locSumAbs value.

20. The step of determining the rice parameter includes the step of deriving the rice parameter from the normalized locSumAbs value according to a lookup table, The lookup table is preferably Table 2 The method according to claim 16, wherein the rice parameter includes cRiceParam, and the method further includes the step of updating the rice parameter according to cRiceParam = cRiceParam + c, where c is based on the shift value.

21. The method according to claim 16, wherein the steps of calculating the locSumAbs value and normalizing the locSumAbs value include the step of calculating the locSumAbs value as equal to (shift == 0) ? locSumAbs : (locSumAbs + (1 << (shift -1) )) >> shift.

22. The step of deriving the shift value includes the step of calculating the shift value as shift = (Bitdepth - b) > 0 ? Floor(Log2(a*(Bitdepth - b))) : 0, The method according to claim 21, wherein Bitdepth preferably specifies the bit depth of the video data, b specifies the operation bit depth, a is set to be equal to an integer power of 2, and c is based on the shift value.

23. The step of deriving the shift value includes the step of calculating the shift value using (Bitdepth - b) > 0) && (locSumAbs - baseLevel * 5) >= T ? Floor(Log2(a*(Bitdepth - b))) : 0, The method according to claim 22, preferably in which T is a predefined threshold.

24. The method according to claim 16, wherein the step of deriving the shift value further includes the step of deriving the shift value according to one or more of the input bit depth, a predefined operation bit depth, local activity of the conversion coefficients, block size, or syntax elements signaled in the bitstream containing the video data.

25. The steps of calculating the locSumAbs value and normalizing the locSumAbs value are: locSumAbs = (shift == 0) ? locSumAbs : (locSumAbs + (1 << (shift -1) )) >> shift, and locSumAbs = (shift1 == 0) ? locSumAbs : (locSumAbs + (1 << (shift1 -1) )) >> shift1 The method according to claim 16, comprising the step of calculating.

26. The step of deriving the shift value is the values ​​of shift and shift1 shift = ((Bitdepth - b) > 0) && (locSumAbs - baseLevel * 5) >= T ? Floor(Log2(a*(Bitdepth - b))) : 0, and shift1 = ((Bitdepth - b) > 0) && (locSumAbs - baseLevel * 5) >= T ? Floor(Log2(a*(Bitdepth - b))) : 0 This includes a step of calculating as follows: The method according to claim 25, wherein T is preferably a threshold, baseLevel represents the original value for the current coefficient, Bitdepth specifies the bit depth of the video data, b specifies the operation bit depth, and a is set to be equal to an integer power of 2.

27. ​​The steps of calculating the locSumAbs value, deriving the shift value, and normalizing the locSumAbs value are shift = (locSumAbs * scl) >= T ? FloorLog2((locSumAbs * scl) >> N) : 0, locSumAbs = locSumAbs >> shift, locSumAbs = Clip3( 0, 31, locSumAbs - baseLevel * 5 ) The step includes calculating, The method according to claim 16, preferably wherein T is a threshold value, scl is a scaling value, and N is the number of bits.

28. The method of claim 27, further comprising the step of determining a value of 8 for T, a value of 3 for N, and scl = floorLog2(bitdepth - 10), wherein bitdepth is a value representing the bit depth of the bitstream containing the video data.

29. The step of deriving a temporary rice parameter value using the locSumAbs value, wherein the step of determining the rice parameter includes calculating the rice parameter as the sum of the temporary rice parameter value and the variable c, The method according to claim 16, wherein the value of c is preferably determined to be equal to the shift value, or derived from the shift value.

30. A computer-readable storage medium storing instructions, wherein when an instruction is executed, it causes a processor to perform the method according to any one of claims 16 to 29.

31. A device for decoding video data, A means for calculating the local sum (locSumAbs value) of the absolute values ​​of the coefficients adjacent to the current coefficient in the current block of video data, Means for deriving a shift value from at least one of the bit depth of the video data and the locSumAbs value, Means for normalizing the locSumAbs value using the shift value to generate a normalized locSumAbs value, Means for determining the rice parameter using the normalized locSumAbs value, Means for decoding the video data using the aforementioned Rice parameters A device equipped with the following features.

Images