# Patent application title: METHODS AND DEVICES FOR DATA COMPRESSION USING A NON-UNIFORM RECONSTRUCTION SPACE

##
Inventors:
Xiang Yu (Kitchener, CA)
Xiang Yu (Kitchener, CA)
Jing Wang (Waterloo, CA)
Jing Wang (Waterloo, CA)
Dake He (Waterloo, CA)
Dake He (Waterloo, CA)

Assignees:
RESEARCH IN MOTION LIMITED

IPC8 Class: AH04N726FI

USPC Class:
37524003

Class name: Television or motion video signal adaptive quantization

Publication date: 2013-04-04

Patent application number: 20130083845

Sign up to receive free email alerts when patent applications with chosen keywords are published SIGN UP

## Abstract:

Encoding and decoding methods are presented that use adaptive
reconstruction levels. Reconstruction space parameters are developed by
an encoder and inserted in the bitstream with the encoded video data. The
reconstruction space parameter may include parameters from which the
decoder can determine the levels for dequantization of the encoded video
data. The reconstruction space parameters may include a first
reconstruction level and a step size between other levels. The first
reconstruction level may not equal the step size. In some cases, neither
may be equal to the quantization step size used to quantize the transform
domain coefficients.## Claims:

**1.**A method of decoding a bitstream of encoded data, the method comprising: extracting reconstruction space parameters from the bitstream, wherein the reconstruction space parameters identify a first reconstruction level and a reconstruction step size for further reconstruction levels, and wherein the first reconstruction level is not equal to the reconstruction step size; decoding the encoded data to obtain a plurality of quantized transform coefficients; and dequantizing each quantized transform coefficient to generate a reconstructed transform coefficient based on the first reconstruction level and the reconstruction step size.

**2.**The method claimed in claim 1, wherein the reconstruction step size does not equal

**2.**sup.m, where m is the number of bits of precision used for representing the reconstruction step size.

**3.**The method claimed in claim 1, wherein dequantizing includes calculating a first level offset based upon the difference between the first reconstruction level and the reconstruction step size, and wherein the reconstructed transform coefficient is calculated from the first level offset plus the product of the quantized transform coefficient and the reconstruction step size.

**4.**The method claimed in claim 1, wherein extracting includes extracting a first set of reconstruction space parameters for luma components and extracting a second set of reconstruction space parameter for chroma components, and wherein dequantizing includes generating reconstructed transform coefficients for luma values using the first set of reconstruction space parameters, and generating reconstructed transform coefficients for chroma values using the second set of reconstruction space parameters.

**5.**The method claimed in claim 1, wherein extracting reconstruction space parameters from the bitstream comprises extracting reconstruction space delta indices, and reconstructing the reconstruction space parameters based on the reconstruction space delta indices and corresponding reconstruction space parameter predictions.

**6.**The method claimed in claim 5, wherein the reconstructed transform coefficients are for a current slice and wherein the reconstruction space parameter predictions are not dependent upon data from another slice.

**7.**A decoder for decoding a bitstream of encoded data, the decoder comprising: a processor; a memory; and a decoding application stored in memory and containing instructions for configuring the processor to extract reconstruction space parameters from the bitstream, wherein the reconstruction space parameters identify a first reconstruction level and a reconstruction step size for further reconstruction levels, and wherein the first reconstruction level is not equal to the reconstruction step size, decode the encoded data to obtain a plurality of quantized transform coefficients, and dequantize each quantized transform coefficient to generate a reconstructed transform coefficient based on the first reconstruction level and the reconstruction step size.

**8.**The decoder claimed in claim 7, wherein the reconstruction step size does not equal

**2.**sup.m, where m is the number of bits of precision used for representing the reconstruction step size.

**9.**The decoder claimed in claim 7, wherein the processor is configured to dequantize by calculating a first level offset based upon the difference between the first reconstruction level and the reconstruction step size, and wherein the reconstructed transform coefficient is calculated from the first level offset plus the product of the quantized transform coefficient and the reconstruction step size.

**10.**The decoder claimed in claim 7, wherein the processor is configured to extract by extracting a first set of reconstruction space parameters for luma components and extracting a second set of reconstruction space parameter for chroma components, and wherein the processor is configured to dequantize by generating reconstructed transform coefficients for luma values using the first set of reconstruction space parameters, and generating reconstructed transform coefficients for chroma values using the second set of reconstruction space parameters.

**11.**The decoder claimed in claim 7, wherein the processor is configured to extract reconstruction space parameters from the bitstream by extracting reconstruction space delta indices, and reconstructing the reconstruction space parameters based on the reconstruction space delta indices and corresponding reconstruction space parameter predictions.

**12.**The decoder claimed in claim 11, wherein the reconstructed transform coefficients are for a current slice and wherein the reconstruction space parameter predictions are not dependent upon data from another slice.

**13.**A non-transitory processor-readable medium storing processor-executable instructions which, when executed, configures one or more processors to perform the method claimed in claim

**1.**

**14.**A method for encoding data, the data including quantized transform domain coefficients, the method comprising: generating reconstruction space parameters based upon the quantized transform domain coefficients, wherein the reconstruction space parameters identify a first reconstruction level and a reconstruction step size for further reconstruction levels, and wherein the first reconstruction level is not equal to the reconstruction step size; entropy encoding the quantized transform domain coefficients; and generating a bitstream containing the encoded quantized transform domain coefficients and the reconstruction space parameters.

**15.**The method claimed in claim 14, wherein the reconstruction step size does not match a quantization step size associated with a quantization parameter specified in the bitstream.

**16.**The method claimed in claim 14, wherein generating includes determining the first reconstruction level using an average of the transform domain coefficients quantized to the first level.

**17.**The method claimed in claim 14, wherein generating includes determining the reconstruction steps size using an average step size between the transform domain coefficients quantized to levels other than the first level.

**18.**The method claimed in claim 14, wherein generating includes generating a first set of reconstruction space parameters for luma components and generating a second set of reconstruction space parameter for chroma components.

**19.**The method claimed in claim 14, wherein generating includes predicting the reconstruction space parameters, determining an error in the prediction, quantizing the error, and encoding the quantized error, and wherein generating the bitstream includes inserting the encoded quantized error in a slice header.

**20.**The method claimed in claim 19, wherein the quantized transform domain coefficients are for a current slice, and wherein predicting the reconstruction space parameters is not dependent upon data from another slice.

**21.**An encoder for encoding transform domain coefficients for a group of coding units, the encoder comprising: a processor; a memory storing the data points; and an encoding application stored in memory and containing instructions for configuring the processor to generate reconstruction space parameters based upon the quantized transform domain coefficients, wherein the reconstruction space parameters identify a first reconstruction level and a reconstruction step size for further reconstruction levels, and wherein the first reconstruction level is not equal to the reconstruction step size, entropy encode the quantized transform domain coefficients, and generate a bitstream containing the encoded quantized transform domain coefficients and the reconstruction space parameters.

**22.**The encoder claimed in claim 21, wherein the reconstruction step size does not match a quantization step size associated with a quantization parameter specified in the bitstream.

**23.**The encoder claimed in claim 21, wherein the processor is configured to generate by determining the first reconstruction level using an average of the transform domain coefficients quantized to the first level.

**24.**The encoder claimed in claim 21, wherein the processor is configured to generate by determining the reconstruction steps size using an average step size between the transform domain coefficients quantized to levels other than the first level.

**25.**The encoder claimed in claim 21, wherein the processor is configured to generate by generating a first set of reconstruction space parameters for luma components and generating a second set of reconstruction space parameter for chroma components.

**26.**The encoder claimed in claim 21, wherein the processor is configured to generate by predicting the reconstruction space parameters, determining an error in the prediction, quantizing the error, and encoding the quantized error, and wherein generating the bitstream includes inserting the encoded quantized error in a slice header.

**27.**The encoder claimed in claim 26, wherein the quantized transform domain coefficients are for a current slice, and wherein the processor is configured to predict the reconstruction space parameters without using data from another slice.

**28.**A non-transitory processor-readable medium storing processor-executable instructions which, when executed, configures one or more processors to perform the method claimed in claim

**14.**

## Description:

**COPYRIGHT NOTICE**

**[0001]**A portion of the disclosure of this document and accompanying materials contains material to which a claim for copyright is made. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure, as it appears in the Patent and Trademark Office files or records, but reserves all other copyright rights whatsoever.

**FIELD**

**[0002]**The present application generally relates to data compression and, in particular, to methods and devices for quantization using a non-uniform reconstruction space.

**BACKGROUND**

**[0003]**Data compression occurs in a number of contexts. It is very commonly used in communications and computer networking to store, transmit, and reproduce information efficiently. It finds particular application in the encoding of images, audio and video. Video presents a significant challenge to data compression because of the large amount of data required for each video frame and the speed with which encoding and decoding often needs to occur. The current state-of-the-art for video encoding is the ITU-T H.264/AVC video coding standard. It defines a number of different profiles for different applications, including the Main profile, Baseline profile and others. A next-generation video encoding standard is currently under development through a joint initiative of MPEG-ITU: High Efficiency Video Coding (HEVC).

**[0004]**There are a number of standards for encoding/decoding images and videos, including H.264, that uses block-based coding processes. In these processes, the image or frame is divided into blocks, typically 4×4 or 8×8, and the blocks are spectrally transformed into coefficients, quantized, and entropy encoded. In many cases, the data being transformed is not the actual pixel data, but is residual data following a prediction operation. Predictions can be intra-frame, i.e. block-to-block within the frame/image, or inter-frame, i.e. between frames (also called motion prediction). It is expected that HEVC will also have these features.

**[0005]**When spectrally transforming residual data, many of these standards prescribe the use of a discrete cosine transform (DCT) or some variant thereon. The resulting DCT coefficients are then quantized using a quantizer that employs a uniform quantization step size, i.e. a uniform partitioning of the data space.

**[0006]**Work in lossy compression, e.g., audio/voice coding, video coding, image coding, etc., tends to focus on improving rate-distortion performance. That is, the objective of most encoding and decoding schemes is to find an optimal balance between distortion and coding rate. A rate-distortion optimization expression of the type J=D+λR is typically used, wherein the Lagrangian multiplier λ represents the desired trade-off between coding rate and distortion.

**[0007]**The reconstruction of the data at a decoder using a uniform reconstruction space that matches the uniform partitioning of the data space by quantization at the encoder does not always realize an optimal rate-distortion performance.

**BRIEF DESCRIPTION OF THE DRAWINGS**

**[0008]**Reference will now be made, by way of example, to the accompanying drawings which show example embodiments of the present application, and in which:

**[0009]**FIG. 1 shows, in block diagram form, an encoder for encoding video;

**[0010]**FIG. 2 shows, in block diagram form, a decoder for decoding video;

**[0011]**FIG. 3 shows an example data space;

**[0012]**FIG. 4 shows an example non-uniform distribution of actual data within a sub-part of the data space;

**[0013]**FIG. 5 shows an example adaptive reconstruction space;

**[0014]**FIG. 6 shows a second example adaptive reconstruction space;

**[0015]**FIG. 7 shows a third example adaptive reconstruction space;

**[0016]**FIG. 8 shows a fourth example adaptive reconstruction space;

**[0017]**FIG. 9 shows, in flowchart form, an example method for encoding data with reconstruction space parameters;

**[0018]**FIG. 10 shows, in flowchart form, an example method for decoding encoded data using reconstruction space parameters;

**[0019]**FIG. 11 shows a simplified block diagram of an example embodiment of an encoder; and

**[0020]**FIG. 12 shows a simplified block diagram of an example embodiment of a decoder.

**[0021]**Similar reference numerals may have been used in different figures to denote similar components.

**DESCRIPTION OF EXAMPLE EMBODIMENTS**

**[0022]**The present application describes methods and encoders/decoders for achieving rate-distortion improvements in lossy data compression. In some embodiments, the data compression process or devices described herein may be applied to the encoding and decoding of audio data, image data, and/or video data. In particular, the present application describes a method and process of data compression that uses a non-uniform reconstruction space for dequantization. Methods and devices are described for determining a non-uniform reconstruction space at an encoder, communicating the parameters for non-uniform reconstruction to a decoder, and application of the non-uniform reconstruction space at the decoder when dequantizing data.

**[0023]**In one aspect, the present application describes a method of decoding a bitstream of encoded data. The method includes extracting reconstruction space parameters from the bitstream, wherein the reconstruction space parameters identify a first reconstruction level and a reconstruction step size for further reconstruction levels, and wherein the first reconstruction level is not equal to the reconstruction step size; decoding the encoded data to obtain a plurality of quantized transform coefficients; and dequantizing each quantized transform coefficient to generate a reconstructed transform coefficient based on the first reconstruction level and the reconstruction step size.

**[0024]**In another aspect, the present application describes a method for encoding data, the data including quantized transform domain coefficients. The method includes generating reconstruction space parameters based upon the quantized transform domain coefficients, wherein the reconstruction space parameters identify a first reconstruction level and a reconstruction step size for further reconstruction levels, and wherein the first reconstruction level is not equal to the reconstruction step size; entropy encoding the quantized transform domain coefficients; and generating a bitstream containing the encoded quantized transform domain coefficients and the reconstruction space parameters.

**[0025]**In a further aspect, the present application describes encoders and decoders configured to implement such methods of encoding and decoding.

**[0026]**In yet a further aspect, the present application describes non-transitory computer-readable media storing computer-executable program instructions which, when executed, configured a processor to perform the described methods of encoding and/or decoding.

**[0027]**Other aspects and features of the present application will be understood by those of ordinary skill in the art from a review of the following description of examples in conjunction with the accompanying figures.

**[0028]**In the description that follows, some example embodiments are described with reference to the H.264 standard for video coding. Those ordinarily skilled in the art will understand that the present application is not limited to H.264 but may be applicable to other video coding/decoding standards, including possible future standards, such as HEVC, multiview coding standards, scalable video coding standards, and reconfigurable video coding standards. It will also be appreciated that the present application is not necessarily limited to video coding/decoding and may be applicable to audio coding/decoding, image coding/decoding, or the lossy coding/decoding of any other data. The present application is broadly applicable to any lossy data compression process that employs quantization irrespective of the type of data being coded/decoded.

**[0029]**In the description that follows, when referring to video or images the terms frame, slice, tile and rectangular slice group may be used somewhat interchangeably. Those of skill in the art will appreciate that, in the case of the H.264 standard, a frame may contain one or more slices. It will also be appreciated that certain encoding/decoding operations are performed on a frame-by-frame basis, some are performed on a slice-by-slice basis, some tile-by-tile, and some by rectangular slice group, depending on the particular requirements of the applicable image or video coding standard. In any particular embodiment, the applicable image or video coding standard may determine whether the operations described below are performed in connection with frames and/or slices and/or tiles and/or rectangular slice groups, as the case may be. Accordingly, those ordinarily skilled in the art will understand, in light of the present disclosure, whether particular operations or processes described herein and particular references to frames, slices, tiles, rectangular slice groups are applicable to frames, slices, tiles, rectangular slice groups, or some or all of those for a given embodiment. This also applies to coding units, groups of coding units, etc., as will become apparent in light of the description below.

**[0030]**In the discussion that follows, reference is made to DCT coefficients and the DCT domain; however, it will be appreciated that this application is not limited to the encoding of DCT coefficients, the encoding of block-based transform coefficients, the encoding of block-based data, or any particular data type.

**[0031]**To the extent that the processes or methods described below are applied to images and/or video they may be applied to a portion of a video or image, such as a frame, a slice, a Group-of-Pictures (GOP), or on any other basis, such as to a coding unit, or group of coding units. To the extent that the process or methods described herein are applied to audio, such as music or voice data, they may be applied to a grouping or sequence of data points, e.g. an audio sample. It should be noted that the terms picture and frame could be used interchangeably.

**[0032]**Reference is now made to FIG. 1, which shows, in block diagram form, an encoder 10 for encoding video. Reference is also made to FIG. 2, which shows a block diagram of a decoder 50 for decoding video. It will be appreciated that the encoder 10 and decoder 50 described herein may each be implemented on an application-specific or general purpose computing device, containing one or more processing elements and memory. The operations performed by the encoder 10 or decoder 50, as the case may be, may be implemented by way of application-specific integrated circuit, for example, or by way of stored program instructions executable by a general purpose processor. The device may include additional software, including, for example, an operating system for controlling basic device functions. The range of devices and platforms within which the encoder 10 or decoder 50 may be implemented will be appreciated by those ordinarily skilled in the art having regard to the following description.

**[0033]**The encoder 10 receives a video source 12 and produces an encoded bitstream 14. The decoder 50 receives the encoded bitstream 14 and outputs a decoded video frame 16. The encoder 10 and decoder 50 may be configured to operate in conformance with a number of video compression standards. For example, the encoder 10 and decoder 50 may be H.264/AVC compliant. In other embodiments, the encoder 10 and decoder 50 may conform to other video compression standards, including evolutions of the H.264/AVC standard, like HEVC.

**[0034]**The encoder 10 includes a spatial predictor 21, a coding mode selector 20, transform processor 22, quantizer 24, and entropy encoder 26. As will be appreciated by those ordinarily skilled in the art, the coding mode selector 20 determines the appropriate coding mode for the video source, for example whether the subject frame/slice is of I, P, or B type, and whether particular coding units (e.g. macroblocks) within the frame/slice are inter or intra coded. The transform processor 22 performs a transform upon the spatial domain data. In particular, the transform processor 22 applies a block-based transform to convert spatial domain data to spectral components. For example, in many embodiments a discrete cosine transform (DCT) is used. Other transforms, such as a discrete sine transform or others may be used in some instances. The block-based transform is performed on a macroblock or sub-block basis, depending on the size of the macroblocks. In the H.264 standard, for example, a typical 16×16 macroblock contains sixteen 4×4 transform blocks and the DCT process is performed on the 4×4 blocks. In some cases, the transform blocks may be 8×8, meaning there are four transform blocks per macroblock. In yet other cases, the transform blocks may be other sizes. In some cases, a 16×16 macroblock may include a non-overlapping combination of 4×4 and 8×8 transform blocks.

**[0035]**Applying the block-based transform to a block of pixel data results in a set of transform domain coefficients. A "set" in this context is an ordered set in which the coefficients have coefficient positions. In some instances the set of transform domain coefficients may be considered a "block" or matrix of coefficients. In the description herein the phrases a "set of transform domain coefficients" or a "block of transform domain coefficients" are used interchangeably and are meant to indicate an ordered set of transform domain coefficients.

**[0036]**The set of transform domain coefficients is quantized by the quantizer 24. The quantized coefficients and associated information are then encoded by the entropy encoder 26.

**[0037]**Intra-coded frames/slices (i.e. type I) are encoded without reference to other frames/slices. In other words, they do not employ temporal prediction. However intra-coded frames do rely upon spatial prediction within the frame/slice, as illustrated in FIG. 1 by the spatial predictor 21. That is, when encoding a particular block the data in the block may be compared to the data of nearby pixels within blocks already encoded for that frame/slice. Using a prediction algorithm, the source data of the block may be converted to residual data. The transform processor 22 then encodes the residual data. H.264, for example, prescribes nine spatial prediction modes for 4×4 transform blocks. In some embodiments, each of the nine modes may be used to independently process a block, and then rate-distortion optimization is used to select the best mode.

**[0038]**The H.264 standard also prescribes the use of motion prediction/compensation to take advantage of temporal prediction. Accordingly, the encoder 10 has a feedback loop that includes a de-quantizer 28, inverse transform processor 30, and deblocking processor 32. These elements mirror the decoding process implemented by the decoder 50 to reproduce the frame/slice. A frame store 34 is used to store the reproduced frames. In this manner, the motion prediction is based on what will be the reconstructed frames at the decoder 50 and not on the original frames, which may differ from the reconstructed frames due to the lossy compression involved in encoding/decoding. A motion predictor 36 uses the frames/slices stored in the frame store 34 as source frames/slices for comparison to a current frame for the purpose of identifying similar blocks. Accordingly, for macroblocks to which motion prediction is applied, the "source data" which the transform processor 22 encodes is the residual data that comes out of the motion prediction process. For example, it may include information regarding the reference frame, a spatial displacement or "motion vector", and residual pixel data that represents the differences (if any) between the reference block and the current block. Information regarding the reference frame and/or motion vector may not be processed by the transform processor 22 and/or quantizer 24, but instead may be supplied to the entropy encoder 26 for encoding as part of the bitstream along with the quantized coefficients.

**[0039]**Those ordinarily skilled in the art will appreciate the details and possible variations for implementing H.264 encoders.

**[0040]**The decoder 50 includes an entropy decoder 52, dequantizer 54, inverse transform processor 56, spatial compensator 57, and deblocking processor 60. A frame buffer 58 supplies reconstructed frames for use by a motion compensator 62 in applying motion compensation. The spatial compensator 57 represents the operation of recovering the video data for a particular intra-coded block from a previously decoded block.

**[0041]**The bitstream 14 is received and decoded by the entropy decoder 52 to recover the quantized coefficients. Side information may also be recovered during the entropy decoding process, some of which may be supplied to the motion compensation loop for use in motion compensation, if applicable. For example, the entropy decoder 52 may recover motion vectors and/or reference frame information for inter-coded macroblocks.

**[0042]**The quantized coefficients are then dequantized by the dequantizer 54 to produce the transform domain coefficients, which are then subjected to an inverse transform by the inverse transform processor 56 to recreate the "video data". It will be appreciated that, in some cases, such as with an intra-coded macroblock, the recreated "video data" is the residual data for use in spatial compensation relative to a previously decoded block within the frame. The spatial compensator 57 generates the video data from the residual data and pixel data from a previously decoded block. In other cases, such as inter-coded macroblocks, the recreated "video data" from the inverse transform processor 56 is the residual data for use in motion compensation relative to a reference block from a different frame. Both spatial and motion compensation may be referred to herein as "prediction operations".

**[0043]**The motion compensator 62 locates a reference block within the frame buffer 58 specified for a particular inter-coded macroblock. It does so based on the reference frame information and motion vector specified for the inter-coded macroblock. It then supplies the reference block pixel data for combination with the residual data to arrive at the reconstructed video data for that macroblock.

**[0044]**A deblocking process may then be applied to a reconstructed frame/slice, as indicated by the deblocking processor 60. After deblocking, the frame/slice is output as the decoded video frame 16, for example for display on a display device. It will be understood that the video playback machine, such as a computer, set-top box, DVD or Blu-Ray player, and/or mobile handheld device, may buffer decoded frames in a memory prior to display on an output device.

**[0045]**It is expected that HEVC-compliant encoders and decoders will have many of these same or similar features.

**Quantization**

**[0046]**For a given block of pixels x with a prediction p, the residual is z=x-p. The residual z is transformed (for example by using a DCT) to generate the set of transform domain coefficients c. The coefficients care quantized using a selected quantization step size q to produce a set of quantized coefficients u. This may be expressed as:

**u**=round(c/q+f) (1)

**[0047]**where an input c is quantized to u by applying the quantization step size q, and 1>f>0 is a rounding offset. Because the quantization output is calculated by a deterministic function, this is also called hard-decision quantization.

**[0048]**The quantization operation can be viewed from a rate-distortion point-of-view. In fact, the quantization operation can be refined so as to select indices u such that the selected indices result in a minimum rate-distortion cost. The minimum rate-distortion cost may be expressed as follows:

**min u c**- u q 2 + λ r ( u ) ( 2 ) ##EQU00001##

**[0049]**In Equation (2), c is the matrix of transform coefficients, q is the quantization step size, and u is the corresponding matrix of indices to which the coefficients have been quantized. The symbol λ is the Lagrangian multiplier, a constant that is determined by end users based on their preference of the coding rate and the video quality. A relatively small λ puts more preference on better quality, while a larger λ emphasizes on a lower coding rate. r(u) represents the rate function by entropy coding for the indices u. The entropy coding may be any suitable or applicable entropy coding scheme. In the case of JPEG images, for example, the coding may be Huffman coding. In the case of H.264 video, the coding may be CAVLC or CABAC coding. Yet other context-dependent or context-independent coding schemes may be applicable in particular embodiments. Clearly, the quantization output from Equation (2) is not given by a deterministic function anymore, but is the output of an optimization process that relates to both the rate and the distortion. Thus, it is named soft-decision quantization.

**[0050]**Example embodiments of soft-decision quantization are described in US patent publication no. 2007/0217506 filed by Yang et al. (hereinafter "Yang"). The Yang publication describes the optimization of u given a fixed q (or more generally the matrix q, for a quantizer in which different step sizes may be used for different coefficient positions). This is termed "soft-decision quantization", since the transform domain coefficients themselves are treated as free-parameters in the rate-distortion optimization. The application of soft-decision quantization to H.264 encoding using CAVLC is described in Yang, and it may include the use of a trellis to search for a set of quantized coefficients u that result in a minimum cumulative rate-distortion for a given entropy encoding scheme. In the example described in Yang, the H.264 CAVLC encoding scheme was used for illustration.

**[0051]**In H.264 and in many other coding schemes the quantization step sizes are predetermined, and in a particular instance the encoder selects one of the quantization step sizes to use for quantizing a particular set of data points, whether a block, slice, frame, etc. The encoder then only needs to transmit an index or indicator so as to inform the decoder which quantization step size was used.

**[0052]**Reference is now made to FIG. 3, which graphically illustrates a portion of a data space 100. In this example, the data space 100 contains the set of data points to be quantized using a selected quantization scheme. Conceptually, in order to perform quantization, the data space 100 may be considered to be partitioned into sub-parts A

_{0}, A

_{1}, . . . A

_{N}, where N+1 is the number of sub-parts. Each sub-part may be referenced by its index i, where i=0, 1, . . . , N. A data point falling within one of the sub-parts A

_{i}is quantized as quantized transform domain coefficient u=index i. Reconstruction levels q

_{u}are at the midpoint of their respective sub-parts. When the decoder reconstructs a data point, it reconstructs it as reconstruction level q

_{u}; in the case of u=i the data point is reconstructed as q

_{i}irrespective of where within the sub-part A

_{i}the actual data point was located. With a quantization step size of q, each reconstruction level q

_{i}is given by iq. If the source data is uniform, then the assumption of a midpoint reconstruction level will result in minimal distortion; however the assumption of a uniform distribution of source data may be inaccurate in many cases.

**[0053]**Reference is now made to FIG. 4, which shows an example sub-part A

_{i}. The midpoint reconstruction level is shown as q

_{i}. The non-uniform distribution of the source data points is shown as reference numeral 102. It will be appreciated that data points with a distribution as shown by 102 would be better represented by an adaptive reconstruction level at or near q

_{i}'. The adaptive reconstruction level may be based upon the actual distribution of data points that are associated with or assigned to the index i, i.e. that are located within the sub-part A

_{i}. The adaptive reconstruction level may be based upon the arithmetic mean or median or mode, in some embodiments. By adjusting the reconstruction level to reflect the distribution of the actual data points within a sub-part A

_{i}, the presently described process compensates for some of the distortion attributable to the non-uniform distribution of the data points when relying upon an assumption of uniformity.

**[0054]**In many data compression processes, when quantization is performed the partitioning of the data space and selection of the reconstruction levels are not considered separately. For example, in ITU-T H.264/AVC, both are subsumed under the selection of a quantization step size. The present applicants have recognized that the partitioning of the data space and the selection of a reconstruction level for each sub-part may be considered separately, and need not be based upon a pre-determined reconstruction level, for example at the midpoint of the sub-part as in ITU-T H.264/AVC.

**[0055]**Thus, the quantization under this process becomes a two-stage operation. First, the data points are assigned to a quantization index (i.e. based on the partitioning of the data space, the data points are grouped into sub-parts). The partitioning/quantization at this first stage may be uniform, non-uniform, predetermined hard-decision quantization, or soft-decision quantization. The step size/partition size may be selected from amongst a preset number of candidate step sizes/partition sizes based on a rate-distortion optimization process. In all these possible variations, the data points are each assigned to one of the indices for the selected quantization partition structure.

**[0056]**Second, the adaptive reconstruction level for one or more of the sub-parts of the partitioned data space (e.g. each index) is determined. The adaptive reconstruction level may be based upon an averaging of actual data points falling within the sub-part(s). The averaging may occur over a block or coding unit, group of blocks or coding units, slice, frame, group-of-pictures (GOP) or other suitable collection of data points given the specific application. It may also occur over a group of coding units or frames having a common quantization parameter qP. In some cases the same frame or GOP may have coding units with different qP, in which case those coding units having the same qP may be considered a group of coding units for the purpose of determining adaptive reconstruction levels for that group of coding units.

**[0057]**The selection of the adaptive reconstruction level for each index may be based upon a rate-distortion analysis. In other words, it may be based upon selecting a reconstruction level that minimizes the total distortion given the actual data points within the sub-part. It may further be based upon minimizing a cost function including distortion from the difference between the reconstruction level and the actual data points and the rate cost associated with transmitting the reconstruction levels. The rate cost associated with transmitting the reconstruction level may be based upon the encoding scheme used to entropy encode the reconstruction levels. The rate may also be dependent upon the mode in which the entropy coder is operating (e.g. bypass mode of CABAC).

**[0058]**Example processes for selecting and applying adaptive reconstruction levels were described in U.S. patent application Ser. Nos. 61/446,528 and 13/155,616, filed Feb. 25, 2011, and Jun. 8, 2011, respectively; the contents of which are hereby incorporated by reference.

**[0059]**One example process described in those earlier applications proposed adaptive reconstruction levels constructed in the format iq+δ

_{i}, where i is the index (also referred to herein as the quantized transform domain coefficient u), q is the quantization step size set by the quantization parameter qP, and δ

_{i}is the offset for the i

^{th}quantization level. FIG. 5 graphically illustrates a reconstruction space 120 constructed in accordance with the format iq+δ

_{i}. As was described in an embodiment in U.S. application No. 61/446,528, offsets may be calculated for some of the reconstruction levels, such as the first three or four, and a common offset (perhaps selected using averaging) may be used for subsequent levels. In this example illustration, the offset δ

_{4}is used for the fourth level and above.

**[0060]**Another example process described in the earlier applications proposed adaptive reconstruction levels constructed in the format i(q+δ), where i is the index (the quantized transform domain coefficient), q is the quantization step size set by the quantization parameter qP, and δ is the offset to the quantization step size. FIG. 6 graphically illustrates a reconstruction space 130 constructed in accordance with this format. It will be noted that this format still results in a uniform reconstruction space, as each level is spaced apart by q+δ.

**[0061]**A possible issue with the former example reconstruction space of the format iq+δ

_{i}is the rate-distortion cost associated with transmitting all the offsets. There may also be insufficient statistics to generate sufficiently accurate offsets to justify the cost for every level. As noted, some levels may use an average offset to address this issue. A possible issue with the latter example reconstruction space of the format i(q+δ) is that the reconstruction space remains uniform, which limits the rate-distortion coding performance gains in quantization design. It will also be noted that both schemes remain based upon the quantization step size q used to quantize the transform domain coefficients at the encoder.

**[0062]**To improve on the rate-distortion performance, the present application proposes a more generic reconstruction space using the format (ia+b

_{i}). In this format, the reconstruction space is partly decoupled from the quantization step size, since a is not necessarily equal to q. As illustrated in FIG. 7, this results in a non-uniform reconstruction space 150, with complete flexibility in design. It will be noted that this format degrades to the format of (iq+δ

_{i}) when a=q. It will also be noted that this format degrades to i(q+δ) when b=0.

**[0063]**It has been noted, however, that the best rate-distortion performance is achieved with a≠q and b

_{i}≠0.

**[0064]**It has also been noted that the transmission cost of signaling b, may be unjustified from a rate-distortion point-of-view, so that the format may be simplified to the format (ia+b). FIG. 8 graphically illustrates a reconstruction space 160 constructed in accordance with this format (ia+b). It will be noted that the first level, e.g. i=1, is at a+b and subsequent levels (i>1) are spaced apart by a.

**[0065]**We can define all the samples (i.e. transform domain coefficients) that fall within the i

^{th}sub-part as c.sup.(i)

_{j}, j=1, . . . , N

_{i}. In this notation, the number of samples within the i

^{th}sub-part is N

_{i}.

**[0066]**In an encoding process, these samples c.sup.(i)

_{j}may be the data from the previous slice, frame, etc., that are then used to determine the reconstruction space for the current slice, frame, etc., if the reconstruction space is signaled at the beginning of the coefficient data, e.g. in the slice header. In one embodiment, the reconstruction space of the current slice may be based upon sample data from the immediate previous slice of the same type and/or the same quantization parameter; and the reconstruction space is signaled in the slice header. In certain cases, statistics collected in such a way may not be stable, for example, the total number of sample data may be smaller than a given threshold. In this case, some default parameters of the reconstruction space may be used. In another embodiment, the reconstruction space may be based upon sample data from the current slice or frame if the reconstruction space parameters are signaled at the end of the slice/frame data; however, this would result in a one-slice/frame delay at the decoder, which may be unacceptable in some implementations.

**[0067]**It will be understood that the quantized transform domain coefficients u, are the transform domain coefficients c quantized using quantization step size q, which may be denoted q

_{q}P below to specify the quantization step size associated with the qP value selected for the particular slice, frame, etc. Note that in some embodiments, the quantized transform domain coefficients u may also incorporate scaling; for example, in some example implementations these values may be scaled by 128 or some other factor (e.g., 2

^{m}, where m is the arithmetic precision in bits) to aid in facilitating efficient computational implementation. Some details of the scaling and related operations are omitted in the following description but will be understood by those ordinarily skilled in the art.

**[0068]**From the transform domain coefficients c.sup.(i)

_{j}an average for the i

^{th}level may be calculated as:

**c**^ ( i ) = ( j c j ( i ) ) N i ( 3 ) ##EQU00002##

**[0069]**One option for deriving the reconstruction space is to minimize the total rate-distortion using, for example, the expression:

**min**

_{a,b}Σ

_{i}Σ

_{j}(c.sup.(i)

_{j}-(ia+b))

^{2}+.lam- da.(r

_{i}) (4)

**[0070]**In this rate-distortion expression, the distortion is given by the difference between the actual coefficients c.sup.(i)

_{j}in the i

^{th}sub-part and the reconstruction space level given by (ia+b). The rate for transmitting the reconstruction space parameters associated with signaling a and b is represented by the rate r

_{i}.

**[0071]**A solution to Equation (4) is given by:

**b**= ( i i j c j ( i ) ) ( i i N i ) - ( i j c j ( i ) ) ( i i 2 N i ) ( i i N i ) 2 - ( i i 2 N i ) ( i N i ) ( 5 ) a = i i j c j ( i ) - b i i N i i i 2 N i ( 6 ) ##EQU00003##

**[0072]**Note that the above operations could also be performed, with suitable modifications, using the (unrounded) quantized transform domain coefficients un.sup.(i)

_{j}, or in some implementations, using the quantized coefficients with fixed precision to reflect actual codec implementations, e.g., un.sup.(i)

_{j}=c.sup.(i)

_{j}/q128.

**[0073]**The structure of the reconstruction space 160 in FIG. 8 allows for an alternative notation to be used. The alternative notation takes advantage of the fact that the first reconstruction level is distinct and all subsequent levels are at even intervals of a apart. The first level may be set as the average value for the first level, i.e. c.sup.(1), which is given by Equation (3) with i=1, i.e.,

**c**^ ( i ) = ( j c j ( i ) ) N i . ##EQU00004##

**Leaving aside the scaling by q**

_{q}P (and in some implementations by fixed values for ease of computational implementation, like 128), the first reconstruction level is given by:

**t**= ( j un j ( 1 ) ) N 1 ( 7 ) ##EQU00005##

**[0074]**where un.sup.(1)

_{j}=c.sup.(1)

_{j}/q

_{q}P128.

**[0075]**Note that the transform domain coefficients quantized to the first level in this example are represented in a scaled format with a few bits arithmetic precision. The scale is by q

_{q}P. The exemplary arithmetic precision is 7 bits, corresponding to the factor of 2

^{7}=128. Note that other arithmetic precision may also be used. The step size between subsequent quantization levels may then be denoted as s. To finds the following expression may be used:

**s**= argmin s i ≧ 2 j ( un j ( i ) - i s ) 2 = i ≧ 2 i j un j ( i ) i i 2 N i ( 8 ) ##EQU00006##

**[0076]**The reconstruction space using this notation may be written in the (ia+b) format wherein a corresponds to s, and b corresponds to t-s. To be precise, in an implementation in which un=c/q

_{q}P*128, then a=s/128×q

_{q}P and b=(t-s)/128×q

_{q}P.

**[0077]**In the present application, the term "reconstruction space parameters" is used to refer to parameters that signal the adaptive reconstruction space. These parameters may include a and b, t and s, or other such parameters as may be defined for signaling the reconstruction space. Note that the reconstruction space parameters (RSP) are distinct from qP, which is used in the H.264/AVC standard to signal the quantization step size q used at the encoder. In the present application, a≠q, which means that s does not result in a reconstruction space step size of q

_{q}P (or to be precise, using the example implementation described above, s≠128; and to be more general, s≠2

^{m}, where m is the arithmetic precision in bits for representing s).

**[0078]**Nevertheless, in one example embodiment the encoder may manipulate qP to adjust the values of the RSPs that are transmitted. For example, assume the quantization step size q

_{q}P is to be selected from the 52 step sizes defined in H.264 and/or HEVC. In this example, the base qP is 25 (which corresponds to q

_{q}P=10), with a 7-bit arithmetic precision for the quantized reconstruction step size parameters. If Equation (8) results in a quantized reconstruction step size parameter s of 160, it corresponds to a reconstruction step size (e.g. a) q

_{s}=160/128*10=12.5. Instead of transmitting the value of s=160 to signal the reconstruction step size of q

_{s}=12.5, the encoder may adjust the qP base value from 25 to 26 (which corresponds to q

_{q}P=11) and may then transmit a quantized reconstruction step size parameter s=12.5/11*128=145. It should be noted that qP is already incorporated into the syntax for the bitstream as slice qP, and a smaller value for the RSPs may reduce the overhead associated with signaling these values.

**[0079]**Reference is now made to FIG. 9, which shows a flowchart of an example method 200 of encoding data. The method 200 includes an operation 202 of quantizing transform domain coefficients using the quantization step size q

_{q}P. It will be understood that in some implementations the quantization operation is combined with the spectral transform operation and is applied to residual data to arrive at the quantized transform domain coefficients.

**[0080]**In operation 204, the encoder generates reconstruction space parameters (RSPs) based upon the quantized transform domain coefficients. For example, the encoder may use Equations (7) and (8), or similar equations, to generate a first level parameter c.sup.(1) (represented and transmitted by t defined in (7)) and a quantized reconstruction step size parameter s. In some implementations, the RSPs may include parameters a and b, as described above. In yet other implementations, the RSPs may include other parameters, such as the first reconstruction level and the reconstruction step size.

**[0081]**In operation 206, the quantized transform domain coefficients are entropy encoded. The entropy encoding may be variable length coding (VLC), arithmetic coding, or any other applicable entropy encoding scheme for the specific implementation, or a combination of various entropy coding schemes/modes. The entropy encoding produces encoded data.

**[0082]**The method 200 then includes operation 208, in which a bitstream is generated (formed) to contain the encoded data and the RSPs. As noted previously, the RSPs may be put in a slice header, or other header location. In such an example, the RSPs are generated based upon the quantized transform domain coefficients from one frame and are then inserted in the slice header before the next frame.

**[0083]**Operation 208 may include encoding the RSPs for efficient transmission. Various techniques may be used to achieve transmission efficiencies. For example, various prediction schemes may be used so that the actual RSP values are not transmitted, but rather a residual value is transmitted from which the decoder can reconstruct the actual RSP value using the same prediction operation as the encoder. Quantization may be used to reduce the size of the RSP values or residual values being transmitted. It will be understood that quantization may introduce distortion in the reconstructed RSP values. Various entropy encoding mechanisms may be used to encode the RSPs for transmission. A number of possible quantization, prediction and encoding options are outlined below.

**[0084]**A prediction RSP, denoted RSP

_{p}, may be generated based upon data known to both the encoder and decoder. For example, the prediction RSP

_{p}may be based upon previously-coded RSPs, the quantization parameter qP, data type, etc. From the difference between the calculated RSPs and the prediction RSP

_{p}, a prediction error RSP

_{d}is then found. The prediction error RSP

_{d}is then quantized to form a prediction error index RSP_delta_idx, which is then entropy encoded for transmission to the decoder. At the decoder, the encoded prediction error index is extracted from the bitstream (e.g. from the slice header) and it is decoded and dequantized to create a reconstructed prediction error.

**[0085]**The syntax for the RSPs in these examples presumes more than one parameter. In some examples, these parameters may include the first quantized level parameter t (corresponding to c.sup.(1)) and the quantized reconstruction step size parameter s. An index i is used to distinguish between parameters. For example index i=1 may refer to the first quantized level parameter t and index i=2 may refer to the quantized reconstruction step size parameter s.

**[0086]**In some embodiments, RSPs may also be specific to a data type and a quantization parameter qP. Data types, may include luma and chroma. In some cases, the data types may specify inter-coding or intra-coding. In yet other implementations, the data types may include luma-inter, luma-intra, chroma-inter, and chroma-intra. Accordingly, the format for specifying a parameter may be given by:

**RSP**[qP][DataType][i]

**[0087]**Using this format, the process for encoding an RSP with index i, quantization parameter qP, and data type DataType is as follows:

**RSP**

_{d}[qP][DataType][i]=RSP[qP][DataType][i]-RSP

_{p}[qP][DataType][- i]

**RSP**_delta_idx[qP][DataType][i]=Q(RSP

_{d}[qP][DataType][i])

**[0088]**The element RSP_delta_idx[qP][DataType][i] specifies the quantization index that is obtained by quantizing the RSP prediction error RSP

_{d}. Note that this quantization operation Q() does not necessarily involve the same quantization step size as qP. The element RSP_delta_idx is entropy coded and transmitted in the bitstream.

**[0089]**At the decoder, RSP is reconstructed from the corresponding received RSP_delta_idx as follows:

**RSP**'[qP][DataType][i]=invQ(RSP_delta_idx[qP][DataType][i])+RSP

_{p}[qP]- [DataType][i] (9)

**[0090]**Where RSP' denotes the reconstruction of RSP parameter, and invQ() denotes the inverse quantization function.

**[0091]**Note that in some embodiments, the resulting RSP'[qP][DataType][i] may be clipped to prevent its value from exceeding some predefined reasonable range. For example, if RSP'[qP][DataType][1]<RSP'[qP][DataType][2], RSP'[qP][DataType][1] may be set to be equal to RSP'[qP][DataType][2] so that the first cell of the resulting quantizer is always no less than the second cell. It has been observed that such a reconstruction space structure may provide improved performance.

**[0092]**There are a number of possible ways to arrive at the prediction RSP

_{p}[qP][DataType][i]. One is to use a fixed default prediction value. The default value may be dependent upon qP, DataType, and/or index i. It may also be dependent upon temporal layer of slice and other factors. An sample default value is described below for the two index example:

**RSP**

_{p}[qP][RSP_TYPE_INTRAY][1]=128

**RSP**

_{p}[qP][RSP_TYPE_INTRAY][2]=128

**RSP**

_{p}[qP][RSP_TYPE_INTRAUV][1]=128

**RSP**

_{p}[qP][RSP_TYPE_INTRAUV][2]=128

**RSP**

_{p}[qP][RSP_TYPE_INTERY][1]=128, if slice temporal layer index≦1

**RSP**

_{p}[qP][RSP_TYPE_INTERY][2]=147, if slice temporal layer of slice>1

**RSP**

_{p}[qP][RSP_TYPE_INTERUV][1]=128 if slice temporal layer index≦1

**RSP**

_{p}[qP][RSP_TYPE_INTERUV][2]=147, if slice temporal layer index>1

**[0093]**The sample default value may also be independent of qP, DataType, and/or index i. An sample default value is described below:

**RSP**

_{p}[qP][RSP_TYPE_INTRAY][i]=128

**RSP**

_{p}[qP][RSP_TYPE_INTRAUV][i]=128

**RSP**

_{p}[qP][RSP_TYPE_INTERY][i]=128

**RSP**

_{p}[qP][RSP_TYPE_INTERUV][i]=128

**[0094]**In another embodiment, the prediction may be derived from previously-coded RSP values. For example, the prediction may be based upon the most recently coded RSP parameter having the same qP and DataType in the current slice. In the two index example, this means one of the RSP parameters serves as the prediction for the other RSP parameter. As an example:

**RSP**

_{p}[qP][DataType][i]=RSP'[qP][DataType][i+1], where RSP'[qP][DataType][i+1] is obtained prior to reconstructing RSP'[qP][DataType][i].

**[0095]**As with the prediction process, there are a number of possible quantization schemes for the RSP values that may be used in various embodiments. In a first example embodiment, uniform quantization may be used. That is, using a given quantization step size q

_{RSP}, the forward and inverse quantization of the prediction error RSP

_{d}is given by:

**RSP**_delta_idx=Q(RSP

_{d})=sign(RSP

_{d})round(abs(RSP

_{d})/q

_{RSP}- +f), and RSP

_{d}'=invQ(RSP_delta_idx)=RSP_delta_idxq

_{RSP},

**[0096]**where 1>f>0 is a rounding offset

**[0097]**The dequantized prediction error is denoted RSP

_{d}'.

**[0098]**In another example embodiment, it has been observed that large RSP are generally preferable in achieving better overall coding performance. Accordingly, in this embodiment the quantization may use a ceiling function.

**RSP**_delta_idx=Q(RSP

_{d})=ceil(RSP

_{d}/q

_{RSP})

**RSP**

_{d}'=invQ(RSP_delta_idx)=RSP_delta_idxq

_{RSP}

**[0099]**In yet a further embodiment, the following quantization scheme may be used:

**RSP**_delta_idx=Q(RSP

_{d})=floor(RSP

_{d}/q

_{RSP})

**RSP**

_{d}'=invQ(RSP_delta_idx)=(RSP_delta_idx+1)q

_{RSP}

**[0100]**In the following illustrative example, RSPd[qP][DataType][1] is first clipped to (-31, 32) and then quantized with a quantization step size of q

_{RSP}=8:

**RSP**_delta_idx[qP][DataType][1]=(Clip3(-31,32,RSP

_{d}[qp][DataType][1])- +31)>>3

**RSP**

_{d}'[qP][DataType][1]=((RSP_delta_idx[qP][DataType][1]+1)<<3- )-31

**[0101]**In the following illustrative example, RSPd[qP][DataType][2] is first clipped to (-31, 32) and then quantized with a quantization step size of q

_{RSP}=4:

**RSP**_delta_idx[qP][DataType][2]=(Clip3(-31,32,RSP

_{d}[qP][DataType][2])- +31)>>2

**RSP**

_{d}'[qP][DataType][2]=((RSP_delta_idx[qP][DataType][2]+1)<<2- )-31

**[0102]**Non-uniform quantizers may also be used in some embodiments. In some example implementations, a non-uniform quantizer may be dynamically developed based upon the statistics for RSP

_{d}.

**[0103]**As the encoding process continues, the statistics for the prediction error of RSP may vary. It may therefore be beneficial to make the quantization adaptive. One example of adaptive quantization is to select between two or more uniform quantizers based on the value of RSPs received from the previous slice. For example, the encoder (and decoder) may denote Q1() and invQ1() as a pair of forward and inverse uniform quantizers with quantization steps size q

_{RSP}=q1 and rounding offset f=1/2. Denote Q2() and invQ2() as a pair of forward and inverse uniform quantizers with quantization steps size q

_{RSP}=q2 and rounding offset f=1/2. Denote RSP'

_{pre}as the reconstruction of RSP for the previous slice. Given two thresholds, Th1 and Th2, the forward quantization of RSP

_{d}is as follows:

**RSP**_delta_idx=Q(RSP

_{d})=sign(RSP

_{d})round(abs(RSP

_{d})/q1+f), for RSP'

_{pre}<Th2 and RSP

_{p}>>Th1;

**RSP**_delta_idx=Q(RSP

_{d})=sign(RSP

_{d})round(abs(RSP

_{d})/q2+f), otherwise

**[0104]**The inverse quantization in this example is given by:

**RSP**

_{d}'=invQ(RSP_delta_idx)=RSP_delta_idxq1, for RSP'

_{pre}<Th2 and RSP

_{pre}>Th1;

**RSP**

_{d}'=invQ(RSP_delta_idx)=RSP_delta_idxq2, otherwise

**[0105]**In this example, it will be appreciated that the quantization is based upon the RSP value from the previous slice. If inter-slice dependency is not permitted, then this example quantization scheme may be modified by the prediction scheme described above in which the prediction is derived based on the coded RSP values from the current slice. In this case, the RSP'

_{pre}will be the RSP already received for the current slice.

**[0106]**The quantized prediction values may be entropy coded in any suitable manner. Example entropy coding schemes that may be used in specific implementations include fixed-length coding, a Golumb-Rice code (for example, based upon the probability distribution of the indices), and a Huffman code (for example, designed based upon the probability distribution of the indices).

**[0107]**The RSP parameters, howsoever they are predicted, quantized and encoded (if at all), are transmitted to the decoder as part of the bitstream. In many embodiments, the encoded parameters may be inserted into a header, such as the slice header. The slice header syntax may specify a function, such as RSP_param( ), for the RSP parameters. An example slice header syntax is given below:

**TABLE**-US-00001 RSP_param( ) { Descriptor RSP_slice_flag u(1) If(RSP_slice_flag) { RSP_interY_flag u(1) if (RSP_interY_flag) { read_RSP_data(RSP_TYPE_INTERY) } RSP_interUV_flag u(1) if (RSP_interUV_flag) { read_RSP_data(RSP_TYPE_INTERUV) } RSP_intraY_flag u(1) if(RSP_intraY_flag) { read_RSP_data (RSP_TYPE_INTRAY); } RSP_intraUV_flag u(1) if(RSP_intraUV_flag) { read_RSP_data (RSP_TYPE_INTRAUV) } } } read_RSP_data (RSP_data_type_id){ for(i=1; i<=2;i++){ RSP_delta_idx[slice_qp][ RSP_data_type_id][i] vlc(v) } }

**[0108]**The association between RSP_data_type_id and the data type names may, in one example, be:

**TABLE**-US-00002 RSP_data_type_id Data type 0 RSP_TYPE_INTERY 1 RSP_TYPE_INTERUV 2 RSP_TYPE_INTRAY 3 RSP_TYPE_INTRAUV

**In the above**, RSP_TYPE_INTERY corresponds to Inter-coded luma data, RSP_TYPE_INTERUV corresponds to Inter-coded chroma data; RSP_TYPE_INTRAY corresponds to Intra-coded luma data; and RSP_TYPE_INTRAUV corresponds to Intra-coded chroma data.

**[0109]**An alternative syntax, in which the transmission of RSP parameters for Chroma (UV) components is dependent upon whether RSP parameters for Luma (Y) components are present, is set out below:

**TABLE**-US-00003 RSP_param( ) { Descriptor RSP_slice_flag u(1) If(RSP_slice_flag) { RSP_interY_flag u(1) if (RSP_interY_flag) { read_RSP_data(RSP_TYPE_INTERY) RSP_interUV_flag u(1) if (RSP_interUV_flag) { read_RSP_data(RSP_TYPE_INTERUV) } u(1) } RSP_intraY_flag u(1) if(RSP_intraY_flag) { read_RSP_data (RSP_TYPE_INTRAY); RSP_intraUV_flag u(1) if(RSP_intraUV_flag) { read_RSP_data (RSP_TYPE_INTRAUV) } } } } read_RSP_data (RSP_data_type_id){ for(i=1; i<=2;i++){ RSP_delta_idx[slice_qp][ RSP_data_type_id][i] vlc(v) } }

**[0110]**In some example implementations, it may sometimes be advantageous to allow different RSP parameters to be used for U and V components, separately. For example, the RSP_TYPE_INTRAUV data type may be replaced by two data types RSP_TYPE_INTRAU and RSP_TYPE_INTRAV. A set of RSP indices will then be transmitted if the corresponding RSP_intraU_flag or RSP_intraV_flag is true.

**[0111]**At the decoder, the RSP_delta_idx values are extracted from the bitstream in accordance with the applicable syntax. Using one of the processed described above, the decoder reconstructs the RSP' values using the applicable prediction and inverse quantization process.

**[0112]**The entropy encoded quantized transform domain coefficients are decoded from the bitstream. The decoder the converts the quantized transform domain coefficients to reconstructed transform coefficients by dequantizing them using the reconstructed RSP' parameters. In the following description of the decoder coefficient reconstruction process, the notation RSP' for reconstructed RSP values is not used; instead for simplicity the notation RSP is used. The reconstructed RSP values continued to be specified using the syntax: RSP[qP][DataType][i].

**[0113]**For the purposes of this example, the RSP parameters are assumed to be the first reconstruction level parameter t and the reconstruction step size parameter s. The index i=1 specifies the first quantized level parameter t and the index i=2 specifies the quantized reconstruction step size parameter s.

**[0114]**Specifically, the semantics definition of the two RSP parameters are:

**[0115]**RSP[slice_qP][RSP_data_type_id][1]: This RSP parameter determines the first reconstruction level for the decoder as denoted by t. Based on a given quantization parameter qP corresponding to a given quantization step size q

_{q}P for the current slice, the reconstruction level determined by RSP[slice_qP][RSP_data_type_id][1] can be calculated as t/128*q

_{q}P, when 7-bit arithmetic precision is used for this parameter t.

**[0116]**RSP[slice_qP][RSP_data_type_id][2]: This parameter determines reconstruction levels other than the first one. It may be called a reconstruction step size, as denoted by s, meaning a reconstruction step size that is to be added to t to determine reconstruction levels other than the first one. For example, the second reconstruction level corresponds to t+s, and can be calculated as (t+s)/128*q

_{q}P, when 7-bit arithmetic precision is used for both parameters s and t.

**[0117]**The entropy decoded indices (i.e. the quantized transform domain coefficients u) are given by u

_{ij}. When the RSP parameters are used as specified in the slice header syntax, the reconstructed transform domain coefficients d

_{ij}are thus generated by the decoder in accordance with:

**d**

_{ij}=(u

_{ij}×Fa+Fb)>>Fc; (10)

**where**,

**Fa**=LevelScale.sub.(nS)×(nS)[qP%6][i][j]×RSP[slice_qP][RSP_da- ta_type_id][2];

**Fb**=(RSP[slice_qP][RSP_data_type_id][1]-RSP[slice_qP][RSP_data_type_id][2- ])×LevelScale.sub.(nS)×(nS)[qP%6][i][j]+iAdd;

**Fc**=iShift+7

**[0118]**It will be understood that LevelScale.sub.(nS)×(nS)[qP %6][i][j] is a scaling operation currently found in the H.264/AVC and H.265/HEVC reconstruction process, as will be understood by those ordinarily skilled in the art.

**[0119]**In some embodiments, the two RSP parameters might exclude some special cases when RSP_slice_flag is set. In these cases, the semantics definition of the two RSP parameters are:

**[0120]**RSP[slice_qP][RSP_data_type_id][1]: This parameter determines the first reconstruction level for the decoder for coding units corresponding to RSP_data_type_id, and is an integer number between (3<<(RSP_PARAM_PRECISION-2)) and (5<<(RSP_PARAM_PRECISION-2)) inclusive, where RSP_PARAM_PRECISION is the precision used to represent the RSP parameters, which is no less than 2. When the parameter RSP_delta_idx[slice_qP][RSP_data_type_id][1] is read from the slice header as specified in the slice header syntax above, RSP[slice_qP][RSP_data_type_id][1] (or equivalently RSP'[slice_qP][RSP_data_type_id][1], as explained above) is derived as described in connection with Equation (9), which should not be equal to the corresponding parameter RSP[slice_qP][RSP_data_type_id][2] (see the definition below). When the parameter RSP_delta_idx[slice_qP][RSP_data_type_id][1] is not read from the slice header (for example, when RSP_slice_flag or the corresponding RSP_data_type_flag is not set), RSP[slice_qP][RSP_data_type_id][1] is set to be a default value of (1<<RSP_PARAM_PRECISION).

**[0121]**RSP[slice_qP][RSP_data_type_id][2]: This parameter determines reconstruction levels other than the first one, and is an integer number between (3<<(RSP_PARAM_PRECISION-2)) and (5<<(RSP_PARAM_PRECISION-2)) inclusive. It may be called a reconstruction step size meaning a reconstruction step size that is to be added to the first reconstruction level to determine the second and above reconstruction levels. When the parameter RSP_delta_idx[slice_qP][RSP_data_type_id][2] is read from the slice header as specified in the slice header syntax above, RSP[slice_qP][RSP_data_type_id][2] (or equivalently RSP' [slice_qP][RSP_data_type_id][2], as explained above) is derived as described in connection with Equation (9), which should not be equal to (1<<RSP_PARAM_PRECISION). When the parameter RSP_delta_idx[slice_qP][RSP_data_type_id][2] is not read from the slice header (for example, when RSP_slice_flag or the corresponding RSP_data_type_flag is not set), RSP[slice_qP][RSP_data_type_id][2] is set to be a default value of (1<<RSP_PARAM_PRECISION).

**[0122]**In yet another embodiment, the scaling operation may further involve a factor LevelScalePerPred.sub.(nS)×(nS)[i][j], where LevelScalePerPred.sub.(nS)×(nS) is a size (nS)×(nS) matrix. That is,

**Fa**=LevelScale.sub.(nS)×(nS)[qP%6][i][j]×LevelScalePerPred.su- b.(nS)×(nS)[i][j]×RSP[slice_qP][RSP_data_type_id][2];

**The factor LevelScalePerPred**.sub.(nS)×(nS)[i][j] is determined from the transform coefficient of the prediction samples p at position (i,j) corresponding to the quantized transform coefficient u

_{ij}. Such scaling may improve visual quality of the reconstructed samples as it is dependent upon the energy distribution of p in the transform domain. For example, LevelScalePerPred.sub.(nS)×(nS)[i][j] may be inverse proportional to the energy of the prediction p in the transform domain multiplied by a value dependent upon the average prediction energy of the frame, the slice, or a defined group of coding units.

**[0123]**Reference is now made to FIG. 10, which shows, in flowchart form, and example method 300 for decoding a bitstream of compressed data.

**[0124]**In operation 302, the decoder extracts RSP data from the bitstream. In a broad sense, the RSP parameters are extracted from the bitstream; although, it will be understood that the parameters may be predicted, quantized, and encoded before being inserted in the bitstream. As a result, in operation 304 the decoder reconstructs the RSP parameters from the RSP data extracted in operation 302, if needed. From the foregoing description, it will be understood that the RSP parameter may, in some embodiments, include the first quantized level parameter t and the quantized reconstruction step size parameter s. Other parameters may be used in other embodiments. It will also be appreciated that a single set of RSP parameters may be provided for all components, or separate RSP parameters for Luma and Chroma components, or separate RSP parameters for inter-coded data and intra-coded data, or separate RSP parameters for Luma-intra data, Luma-inter data, Chroma-intra data, and Chroma-inter data. Further permutations will be understood in light of the foregoing description of example embodiments.

**[0125]**It will also be understood that the RSP data may be referred to or labeled as one or more "syntax elements" within a raw byte sequence payload (RBSP). The RBSP is a syntax structure containing an integer number of bytes encapsulated in a Network Abstraction Layer (NAL) unit, wherein a NAL unit may contain a data type indication and one or more RBSPs. Other structures for the data in the bitstream and, in particular, the encapsulation of the RSP data within various data structures in the bitstream, are also contemplated. It will be appreciated that operation 302 may include extracting the RSP data from the NAL unit and/or RBSP and/or other data structures in the bitstream.

**[0126]**In operation 306, the decoder decodes the compressed data to recover the quantized transform coefficients u

_{ij}(i.e. the indices). In operation 308, the decoder reconstructs the transform coefficients using the reconstructed RSP parameters. In one example implementation the decoder uses a process like that described in connection with Equation (9).

**[0127]**In another embodiment, the reconstructed transform domain coefficients d

_{ij}may be generated by the decoder in accordance with:

**d**

_{ij}=sgn(u

_{ij})×(abs(u

_{ij})×Fa+Fb)>>Fc;

**where**,

**Fa**=LevelScale.sub.(nS)×(nS)[qP%6][i][j]×RSP[slice_qP][RSP_da- ta_type_id][2];

**Fb**=(RSP[slice_qP][RSP_data_type_id][1]-RSP[slice_qP][RSP_data_type_id][2- ])×LevelScale.sub.(nS)×(nS)[qP%6][i][j]+iAdd;

**Fc**=iShift+7

**where sgn**( ) is a sign function and abs( ) returns the absolute value of its input. Note that LevelScale.sub.(nS)×(nS)[qP %6][i][j] may be degraded to LevelScale.sub.(nS)×(nS)[qP %6], which is independent of the indices of i and j.

**[0128]**In another embodiment, the reconstructed transform domain coefficients d

_{ij}may be generated by the decoder in accordance with:

**[0129]**if (u

_{ij}>0)

**d**

_{ij}=(u

_{ij}×Fa+Fb)>>Fc;

**[0130]**else if (u

_{ij}=0) d

_{ij}=0;

**[0131]**else d

_{ij}=(u

_{ij}×Fa+Fb')>>Fc;

**[0132]**where Fb'=(RSP[slice_qP][RSP_data_type_id][2]-RSP[slice_qP][RSP_data_type_id][1- ])×LevelScale.sub.(nS)×(nS)[qP %6][i][i]+iAdd;

**[0133]**It will be understood that, in some embodiments, the inverse-quantization and inverse-transform processes may be mathematically performed together. Accordingly, the output of the overall process may be reconstructed residuals (e.g. inverse-quantized inverse-transformed coefficients).

**Simplification One**

**[0134]**The mapping between qP and the 52 quantization step sizes in H.264/AVC and the current HEVC development is given by:

**[0135]**Double q

_{QP}[52]={0.625, 0.6875, 0.8125, 0.875, 1.000, 1.125, 1.250, 1.375, 1.625, 1.750, 2.000, 2.250, 2.500, 2.7500, 3.250, 3.500, 4.000, 4.500, 5.000, 5.500, 6.500, 7.000, 8.000, 9.000, 10.000, 11.000, 13.000, 14.0000, 16.000, 18.000, 20.000, 22.000, 26.000, 28.000, 32.000, 36.000, 40.000, 44.000, 52.000, 56.000, 64.000, 72.0000, 80.000, 88.000, 104.000, 112.000, 128.000, 144.000, 160.000, 176.000, 208.000, 224.0000};

**[0136]**One possible simplification of the above-described processes is to determine at the encoder the new quantized reconstruction step size s, and round it to a near step size from the existing set of 52 q

_{QP}step sizes. For example, s may be computed as:

**s**= argmin s i ≧ 1 j ( un j ( i ) - i s ) 2 = i ≧ 1 i j un j ( i ) i i 2 N i ( 11 ) ##EQU00007##

**[0137]**Note that this is the same as Equation (3), but ranges over i≧1. The desired reconstruction step size q

_{next}for may then be calculated by

**q**

_{next}=s/128q

_{QP}[qP

_{used}]

**[0138]**Where qP

_{used}is the current qP for the slice, so q

_{QP}gives the quantization step size actually used in the current slice for quantizing transform domain coefficients. The reconstruction qP

_{next}may be found by mapping the desired reconstruction step size q

_{next}back to a quantization parameter using the q array as follows:

**TABLE**-US-00004 for(Int v=0; v<52; v++) { if(q

_{next}< (q[v] + q[v+1])/2) { qP

_{next}= Clip3(qP

_{used}- 3, qP

_{used}+ 3, v); break; }

**[0139]**When only one qP

_{next}is transmitted for one slice, it can be transmitted without changing any syntax of the current HEVC. However, as the statistics for Luma and Chroma components are very different from each other, some extra gain may be achieved if Equation (11) is computed for different type of data such as Luma and Chroma, and a corresponding qP

_{next}is transmitted to be used by Luma and Chroma.

**Simplification Two**

**[0140]**In another example, the RSPs for the Luma and Chroma components are represented by the corresponding Luma and Chroma quantization parameters (qP): qP

_{Y}and qP

_{UV}, respectively. In the current slice header described in HEVC, the syntax element slice_qp_delta is transmitted to specify an initial value of qP

_{Y}. Accordingly, the syntax may be modified to provide for syntax element slice_chroma_qp_delta to be transmitted in the slice header, which is used to specify an initial value of QP

_{UV}.

**[0141]**The syntax element slice_chroma_qp_delta in this example specifies the initial value of qP

_{UV}to be used for all the macroblocks in the slice until modified by the value of cu_qp_delta in the coding unit layer. The initial qP

_{UV}quantization parameter for the slice may be computed as:

**SliceQP**

_{C}=SliceQP

_{Y}+slice_chroma_qp_delta

**[0142]**The value of slice_chroma_qp_delta may be limited such that SliceQP

_{C}is in the range of -QpBdOffset

_{C}to +51, inclusive.

**[0143]**The value of qP

_{UV}may derived as

**QP**

_{C}=(((QP

_{C},PRED+cu_qp_delta+52+2*QpBdOffset

_{C})%(52+QpBdOff- set

_{C}))-QpBdOffset

_{C}

**[0144]**where QP

_{C},PRED is a prediction value of the chroma quantization parameter QP

_{C}, which may be derived from the luma or chroma quantization parameters of previously-decoded coding units in the current slice or previous slices. In one example, QP

_{C},PRED may be derived as the chroma quantization parameter of the left neighbor quantization group of coding units in the current slice. If the left neighbor quantization group in the current slice is not available, QP

_{C},PRED may be derived as the chroma quantization parameter, of the previous quantization group in decoding order in the current slice. For the first quantization group of coding units in the slice QP

_{C},PRED may be initially set equal to SliceQP

_{C}at the start of each slice.

**[0145]**The value of QP'

_{C}may be derived as QP'

_{C}=QP

_{C}+QpBdOffset

_{C}.

**[0146]**Reference is now made to FIG. 11, which shows a simplified block diagram of an example embodiment of an encoder 900. The encoder 900 includes a processor 902, memory 904, and an encoding application 906. The encoding application 906 may include a computer program or application stored in memory 904 and containing instructions for configuring the processor 902 to perform steps or operations such as those described herein. For example, the encoding application 906 may encode and output bitstreams encoded in accordance with the adaptive reconstruction level process described herein. The input data points may relate to audio, images, video, or other data that may be subject of a lossy data compression scheme. The encoding application 906 may include a quantization module 908 configured to determine an adaptive reconstruction level for each index of a partition structure. The encoding application 906 may include an entropy encoder configured to entropy encode the adaptive reconstruction levels or RSP data, and other data. It will be understood that the encoding application 906 may be stored in on a computer readable medium, such as a compact disc, flash memory device, random access memory, hard drive, etc.

**[0147]**Reference is now also made to FIG. 12, which shows a simplified block diagram of an example embodiment of a decoder 1000. The decoder 1000 includes a processor 1002, a memory 1004, and a decoding application 1006. The decoding application 1006 may include a computer program or application stored in memory 1004 and containing instructions for configuring the processor 1002 to perform steps or operations such as those described herein. The decoding application 1006 may include an entropy decoder and a de-quantization module 1010 configured to obtain RSP data or adaptive reconstruction levels and use that obtained data to reconstruct transform domain coefficients or other such data points. It will be understood that the decoding application 1006 may be stored in on a computer readable medium, such as a compact disc, flash memory device, random access memory, hard drive, etc.

**[0148]**It will be appreciated that the decoder and/or encoder according to the present application may be implemented in a number of computing devices, including, without limitation, servers, suitably programmed general purpose computers, audio/video encoding and playback devices, set-top television boxes, television broadcast equipment, and mobile devices. The decoder or encoder may be implemented by way of software containing instructions for configuring a processor to carry out the functions described herein. The software instructions may be stored on any suitable non-transitory computer-readable memory, including CDs, RAM, ROM, Flash memory, etc.

**[0149]**It will be understood that the encoder described herein and the module, routine, process, thread, or other software component implementing the described method/process for configuring the encoder may be realized using standard computer programming techniques and languages. The present application is not limited to particular processors, computer languages, computer programming conventions, data structures, other such implementation details. Those skilled in the art will recognize that the described processes may be implemented as a part of computer-executable code stored in volatile or non-volatile memory, as part of an application-specific integrated chip (ASIC), etc.

**[0150]**Certain adaptations and modifications of the described embodiments can be made. Therefore, the above discussed embodiments are considered to be illustrative and not restrictive.

**Computer Program Listing Appendix**

**[0151]**By way of example, and without limitation, the accompanying ASCII text file entitled 43140-US-PAT_code_listing.txt contains example code subroutines and/or listings providing example implementations of various operations. The content of the ASCII text file is hereby incorporated by reference. Specific routines found in the text file include:

**[0152]**1. RSP computation: routines for determining the RSPs for a slice based on data from the previous slice;

**[0153]**2. Applying the new level to deQ: dequantization with the adaptive reconstruction levels

**[0154]**3. Data Collection: a reconstruction level data collection routine;

**[0155]**4. RSP transmitting: routine for coding RSP data in the slice header; and

**[0156]**5. RSP receiving: routing for decoding RSP data from the slice header.

**[0157]**It will be appreciated that these example routines and code listings are examples of portions of the code listing used in implementing and encoder and/or decoder in accordance with one embodiment of the present application, and are not a complete processor-executable code listing for either an encoder or decoder.

User Contributions:

Comment about this patent or add new information about this topic: