Abstract:
Inverse transforms used in video and image compression/decompression, such as DCT/IDCT used in MPEG-2 and MPEG-4, or the integer transforms used in H.264, are usually calculated with fast algorithms, which only take advantage of the symmetry existing in the transform matrix but ignores the peculiarities in the input data. While these kind of fast algorithms can apply to both forward and inverse transforms, they tend to be inefficient in calculating inverse transforms. In inverse transforms, most of the coefficients become zero after quantization, this invention takes advantage of this fact to further simplify the general fast algorithm and speed up the calculation.

Description:
CROSS REFERENCE 
       [0001]    This application claims priority from a provisional patent application entitled “Methods and Circuits for Video Inverse Transform” filed on Aug. 20, 2007 and having an Application No. 60/956,915. Said application is incorporated herein by reference. 
     
    
     FIELD OF INVENTION 
       [0002]    This invention relates generally to compressed video decoding, and, in particular, to methods for reducing the amount of computations used for inverse transforms for a compressed video. 
       BACKGROUND 
       [0003]    Most of the video and image compression standards in commercial use, for example, MPEG-2, MPEG-4, H.264 and JPEG, are based on block motion estimation and transformation. On the encoding side, motion estimation is made on previously encoded and reconstructed reference pictures; the residual between the pixels on the current picture and the prediction from motion estimation is transformed; the coefficients will be quantized, converted into 1-dimension through a process called zigzag; further compressed with variable length coding (VLC); and then wrapped up into bit stream based on the specific syntax of the standard. 
         [0004]    On the decoding side, inverse transform is an essential part of the decompression procedure, which is usually very time consuming as well. Reducing the computation required to decompress video is not only one of the main interests in the academic community, but the industry has also put a lot of effort as well in order to enable commercial applications derived from these video standards. 
         [0005]    Generally, fast algorithms are developed and used to reduce the computation required in both the forward transform and inverse transform. These fast algorithms are usually derived by taking advantage of the symmetrical properties existing in the transform matrix elements and the linearity of the transforms. It does not assume any other properties in the input data, so the fast algorithms for forward transform and inverse transform are usually very similar. Typical examples of these kind of fast algorithms include FFT (Fast Fourier Transform), various fast transforms developed in DCT (Discrete Cosine Transform), etc. 
         [0006]    While these kind of fast algorithms save a lot of computations when compared to some brute-force methods, when applied to inverse transform, they fail to take advantage of other important properties existing in the input data (i.e. transform coefficients) which can be used to further reduce the number of computations. Among the transform coefficients taken as input data in inverse transform, many of them become zero after quantization, another essential step to achieve video/image data compression on the encoding side. For example, it is quite common in the H.264 based video stream, that 4×4 block will only have 1 or 2 non-zero coefficients, while the generic fast algorithm blindly assumes all 16 coefficients are non-zero. 
         [0007]    The number zero possess the much desired elegance that when it is multiplied to another number the product is zero, and the sum is just the other operand when it is added to another number. If these simple properties of the number zero are ingeniously taken advantage of, computation can be further reduced. Reduction of computations will lead to other advantages, for example, handheld electronic devices derived from video decompression can run at lower frequency so as to save power. 
       SUMMARY OF INVENTION 
       [0008]    Briefly, the present invention relates to methods for calculating an inverse transform of input data, wherein said input data having a plurality of coefficients, and may comprise the steps of: determining a plurality of computation modes; representing said computation modes by a plurality of representative computation modes as a function of the non-zero coefficients of the input data; selecting one of the representative computation modes as a function of the input data; and inverse transforming the input data using said selected representative computation mode. 
     
    
     
       DESCRIPTION OF THE DRAWINGS 
         [0009]    Computations can be further reduced by using methods which take advantage of the peculiarities in the input data, specifically, the many zeros in the input data of the inverse transform in video/image decompression, which will be described in detail in this invention in conjunction with the drawings, wherein, 
           [0010]      FIG. 1  illustrates an inverse transform of the scaled transform coefficients for residual 4×4 blocks as defined in the H.264 standard. 
           [0011]      FIGS. 2A-2D  illustrate the computation mode where all the 16 scaled coefficients are non-zeros, where the original input dij(i=0, . . . 3, j=0 . . . 3) in  FIG. 1  are renamed to xk with k=0, . . . , 15. 
           [0012]      FIG. 3  illustrates the computation mode where only x0, x1, x2 and x3 are non-zeros while all other coefficients are zeros. 
           [0013]      FIG. 4  illustrates certain computation modes where the modes in the left can be computed by using the modes in the right if there is an arrow from the left to the right. 
           [0014]      FIG. 5A  illustrates a procedure for computing the inverse transform with a single computation mode in the prior art. 
           [0015]      FIG. 5B  illustrates a procedure for computing the inverse transform with one of the frequently occurring representative computation modes. 
           [0016]      FIG. 6  illustrates a procedure for computing the inverse transform by matching the pattern of input data with a representative computation mode. 
       
    
    
     DESCRIPTION OF THE PREFERRED EMBODIMENTS 
       [0017]    In the most generic sense, the inverse transform can be abstracted as mathematical processing of a plurality of input data to generate a plurality of output data. There are no constraints regarding the input data, nor the mathematical processing. For example, the input data can have more zeros or less zeros, or no zeros at all. The mathematical processing can be linear or non-linear. Though typical examples can be taken from video/audio compression and decompression, the applicability of the invention should be understood at its broadest coverage. Without loss of generality, throughout this description we will use an example in  FIG. 1 , which is the inverse transformation of the scaled transform coefficients for residual 4×4 blocks as defined in H.264 standard. 
         [0018]    Computation Mode (denoted as compu_mode for short): computation mode is a term defined in this invention to be the fast algorithm developed in considering properties of both the (inverse) transform and the input data. This contrasts to the prior art that only the properties of the transforms were investigated and effectively used when developing fast algorithms, while the peculiarities in the input data were not used at all. The properties of the (inverse) transform, for example, consist of the symmetry of constant multipliers used to manipulate the input data. The peculiarities of the input data, for example, manifest themselves as the many zeros. When considering both a specific transform and the input data, a computation mode will be only defined by the characteristics of the input data if the transform is unambiguously defined mathematically. Without loss of generality, in the description of this invention, a computation mode is associated with the number and the locations of the zeros in the input data. For each computation mode, a specific fast algorithm can be developed. In this document, a different computation mode is represented by a different sequence of atomic computations. An atomic computation is one that cannot be further decomposed into even simpler computations given the computing resources. In this description, for illustrative purposes, the atomic computations are defined to include addition, subtraction, multiplication and right shift, all in integers. 
         [0019]    Computation Cost (denoted as compu_cost for short): The computation cost is defined as the amount of physical resources used to realize the computation. For example, the physical resource can be memory size or cycles. In this description, the number of atomic computations are used to represent the cost, since it is closely related to the number of cycles required to do the computation. In general, different computation modes should have different computation costs though some may happen to be the same. 
         [0020]    Examples of computation modes:  FIGS. 2A-2D  illustrate the computation mode where none of the 16 scaled coefficients are zero; as can be seen, there are 100 computations in the sequence and so the computation cost is 100.  FIG. 3  illustrates another computation mode where only the first four coefficients are non-zeros while all other coefficients are zeros. The computation cost for the computation mode illustrated by  FIG. 3  is 27. As can be seen, the computation mode illustrated by  FIG. 3  is much more efficient than the computation mode illustrated by  FIG. 2 . 
         [0021]    Number of distinctive computation modes: Ideally, the zeros and their locations in the input data will uniquely define a computation mode that will be optimal for the particular input data. So the number of distinctive computation modes will be 2̂n assuming that there are n coefficients in the input data. In the case of residual 4×4 blocks in H.264, since there are 16 coefficients in the input, so there will be 2̂16=65536 distinctive computation modes. In the case of 8×8 inverse transform in MPEG-2, the number will be even more mind-boggling reaching 2̂64. To simplify the description, when the number of coefficients in the input is n, the computation mode is denoted with an n-bit integer number, where the n-th bit location is associated with the n-th coefficient in the input data. For example, compu_mode(254), or compu_mode(0x00fe) in hexadecimal format, will be optimal for input data where the 1 to 7-th coefficients are non-zeros while all the other coefficients are all zeros. 
         [0022]    Relationship between computation modes and input data: To incorporate all the distinctive computation modes in an implementation and dispatch a set of input data to its optimal computation mode will not be practical in reality due to the large number of distinctive computation modes. In fact, even if it is possible to do so, it is not economical in terms of implementation cost, since some of the computation modes will be rarely used. Fortunately, a computation mode as defined above has the nice property that one computation mode can be employed to calculate more than one set of input data, and on the other hand, a set of input data can be calculated by more than one computation mode. Using the H.264 residual 4×4 block example, an input set with only the 0-th coefficient is non-zero can be calculate by compu_mode(0x0001), compu_mode(0x0003), and compu_mode(0x000f), etc. By the same token, comp_mode(0xffff) can be used to calculate all input sets. In general, whether a computation mode x can be computed by another computation mode y or not can be determined by checking all the corresponding bits of x and y. Denoting the i-th bit of x and y to be xi and yi and the result of the check at the i-th bit to be zi, then zi=(˜xi+yi), where ˜xi means the logical negation of xi. Mode x can be computed by mode y if at every bit location zi is true. 
         [0023]    Some examples to show whether one computation mode can be computed by another mode or not: In  FIG. 4 , there are some computations on the left and some others on the right. The computations on the left can be computed by the computation mode on the right if there is an arrow going from the left to the right. To clarify with better visualization, the computation mode numbering is expressed in both hexadecimal and binary format. 
         [0024]    Representative computation modes: In reality, some frequently occurring computation modes will be singled out to handle all the input data and they will be called representative computation modes. The question of how many representative computation modes to use is a matter of design trade-off consideration. Which computation modes will be qualified as frequently occurring representative modes can be solved by a plurality of methods, which can be generally categorized as statistical methods or educated guess methods, or the combination of the two with some modification. The statistical methods find frequently occurring representative modes by running large numbers of streams and building a histogram. The educated guess methods directly result from the principles of transform based video compression. For example, it is known that compu_mode(0xfff0) should be more frequently occurring than compu_mode(0xffff). To simplify the description, a mode which is picked up as one of the frequently occurring representative modes will be denoted as frequ_mode(pat_id), where pat_id is the number to indicate the input data pattern. Note that frequ_mode(pat_id) and compu_mode(pat_id) are basically the same. Some other examples will be given in embodiment 1 and embodiment 2 as follows. 
         [0025]    Embodiment 1: The number of frequently occurring modes is determined based on the number of trailing zeros in the coefficients in the input data. For example, it can be assumed that there are 7 frequently occurring representative computation modes: frequ_mode(0xc000), frequ_mode(0xf000), frequ_mode(0xfc00), frequ_mode(0xff00), frequ_mode(0xffc0), frequ_mode(0xfff0) and compu_mode(0xffff). Note that compu_mode(0xffff) should always be included so that it will take care of those input data patterns which cannot be handled by other representative modes. 
         [0026]    Embodiment 2: The number of frequently occurring representative modes is determined based on “decimating” the coefficients into multiple frequency groups. A group is considered to be zero only when all the coefficients are zeros. In the case of H.264 4×4 residual block, if every consecutive two coefficients after zigzag are combined into one group, there will be 255 frequently occurring representative modes which can be denoted as compu_mode(0x01) to compu_mode(0xff). Note that compu_mode(0x00) is a degenerated trivial case where all the coefficients are zero and so no computation is needed. 
         [0027]    Inverse transform computation based on multiple representative computation modes: In the prior art, given the inverse transform is unambiguously mathematically defined, it is always computed using the same atomic computation sequence without looking into the peculiarities of the input data pattern. In the case of H.264 4×4 residual block, the prior art essentially use the compu_mode(0xffff) only. With the introduction of multiple representative computation modes, inverse transform computation starts with finding a best mode from the representative modes first, followed by assigning the computation to that mode. One of the differences between the prior art and this invention is shown by  FIGS. 5A-5B . As shown in  FIG. 5A , the prior art takes the input data  100 , does the computation  102 , and outputs the results  104 . In this invention, the input data  100  is fed to a mode assignor  106 , which generates control signals  110  to select one of the representative computation modes  108 , and the control signals are also fed to the an output selector  112  to generate the output  104 . 
         [0028]    Assigning a representative computation mode to the input data: the mode assignor  106  assigns a representative computation mode to the input data  100  based on several considerations. The first consideration is that the representative computation mode should indeed be capable of computing the inverse transform, i.e. functionally correct when compared to the result from the mathematical definition of the inverse transform. The second consideration is that the assignor should preferably make the decision relatively quick in order that the overall time of the computation is much less than the prior art. Note that the decision made by the assignor may not necessarily be optimal from a computational point of view in order to trade for less complexity. Various methods can be employed to design the assignor in conjunction with the selected representative modes. Some examples will be given in embodiment 3, embodiment 4, and embodiment 5. 
         [0029]    Embodiment 3: If the frequently occurring representative computation modes are determined by the method described in Embodiment 1, the representative computation modes can be found by checking the variable length decoding (VLD) results based on whether each coefficient is zero or not. 
         [0030]    Embodiment 4: In the case that the frequently occurring representative computation modes do not show any explicit regularity, such as those obtained by collecting statistics by running large amounts of testing streams, the assignor can make its decision by checking the input data against each frequently occurring mode first; if there are more than 1 mode that can meet the condition, the assignor can select the one with the least computation cost or randomly select one if there are multiple representative modes with the same least computation costs. This procedure is shown as a two-stage decision making procedure in  FIG. 6 , where the implementation is implied to be hardware based, though the same idea can be easily implemented in software as well. Assuming there are n frequently occurring representative computation modes corresponding to the n pattern matchers  204  in  FIG. 6 , the input data  200  is first passed through zero/non-zero comparators  202  with one for each transform coefficient, then fed to every pattern matcher  204  to check whether it matches any specific frequently occurring representative mode or not. The results from the pattern matchers  206  are further fed into the confliction resolver  208  in case the input data matches more than 1 frequently occurring representative modes, and the confliction resolver  208  selects only one computation mode as the final result  210 . 
         [0031]    While the present invention has been described with reference to certain preferred embodiments or methods, it is to be understood that the present invention is not limited to such specific embodiments or methods. Rather, it is the inventor&#39;s contention that the invention be understood and construed in its broadest meaning as reflected by the following claims. Thus, these claims are to be understood as incorporating not only the preferred methods described herein but all those other and further alterations and modifications as would be apparent to those of ordinary skilled in the art.