Abstract:
The present invention relates to a system for the parallel processing of a number of binstream bins comprising: (a) inputs for receiving the codIOffset, the codIRange and the bitstream suffix bits; (b) a first circuit for the parallel processing of said number of said bitstream suffix bits, said codIOffset, and said codIRange for producing an indication of the binstream suffix length magnitude; (c) a second circuit for the parallel processing of said number of said bitstream suffix bits, said codIOffset, and said codIRange for producing said number of speculative codIOffsets; (d) a third circuit for combining the products of said first circuit and the products of said second circuit for producing a new codIOffset; and (e) a fourth circuit for combining the products of said first circuit with said number of constants for producing a number indicative of the binstream suffix length.

Description:
FIELD OF THE INVENTION 
       [0001]    The present invention relates to the field of digital video decoding systems. More particularly, the invention relates to a system for the simultaneous parallel decoding of a number of suffix bits from an encoded bitstream, according to the context adaptive binary arithmetic decoding scheme described in the H.264 standard. 
       BACKGROUND OF THE INVENTION 
       [0002]    The increasing demand to improve the quality of transmitted video has prompted rapid advancements in video compression techniques. During the last decade, many ISO/ITU standards on video compression have evolved, such as standard ISO/14496-10:2005 AVC referred to hereinafter as the H.264 standard. This standard exploits the spatial and temporal correlation in the video data and utilizes entropy coding techniques to achieve a high compression ratio. One of the standard&#39;s compression techniques uses the DCT transform, which can transform a block of an image pixel into coefficients that are energy concentrated around the low frequency region, effectively exploiting the spatial correlation of the video. Another technique disclosed in the H.264 standard is the use of motion vectors which are two-dimensional vectors used for inter prediction that provide an offset from the coordinates in the decoded picture to the coordinates in a reference picture, effectively exploiting the temporal correlation of the video. Entropy coding is a loss-less compression process that is based on the statistical properties of data. The entropy machines first assign codes to symbols so as to match code lengths with the probabilities of occurrence of the symbols. The basic idea is to express the most frequently occurring symbols with the least number of bits. 
         [0003]    Due to its high compression efficiency, the Arithmetic coding has been chosen for the H.264 standard as the higher compression mode. The H.264 supported arithmetic coding is combined with context-adaptive modeling techniques and is known as the Context-based Adaptive Binary Arithmetic Coding (CABAC). The context-adaptive modeling techniques use local spatial and temporal characteristics to estimate the probability of a symbol. Thus, context-adaptive modeling has shown an even better compression results compared to the other forms of coding, as the successful entropy coding depends largely on accurate models of symbol probability. 
         [0004]    The CABAC encoding algorithm includes three basic steps: binarization, context modeling, and binary arithmetic encoding. In the H.264 standard, context modeling and the binary arithmetic engine approximate the generic arithmetic encoder using quantization. 
         [0005]    At first, a syntax element, is mapped to a unique binary sequence of bins called binstring. The process of converting a syntax element value to a binary sequence is referred to hereinafter as binarization, 
         [0006]    Arithmetic coding is based on the principle of recursive interval subdivision. Given a probability estimation p(‘0’) and p(‘1’)=1−p(‘0’) of a binary decision (‘0’, ‘1’), an initially given interval with lower bound L and with range R will be subdivided into two sub-intervals having range p(‘0’)×R and R−p(‘0’)×R, respectively. Depending on the decision, which has been observed, the corresponding sub-interval will be chosen as the new code interval, and a binary code string pointing into that interval will represent the sequence of observed binary decisions. It is useful to distinguish between the most probable symbol (MPS) and the least probable symbol (LPS), so that binary decisions have to be identified as either MPS or LPS, rather than ‘0’ or ‘1’. Given this terminology, each context model CTX is defined by the probability pLPS of the LPS and the value of MPS, which is either ‘0’ or ‘1’. 
         [0007]    The range R representing the state of the coding engine is quantized to a small set {Q 1 , . . . ,Q 4 } of pre-defined quantization values prior to the calculation of the new interval range. Versus generic arithmetic encoding, storing a table containing all 64×4 pre-computed product values of Qi×Pk allows a multiplication-free approximation of the product R×Pk. 
         [0008]    For syntax elements or parts thereof with an approximately uniform probability distribution a separate simplified bypass encoding and decoding path is used. 
         [0009]    In the context modeling step, each bin is assigned a probability context model, which includes information on whether the bin is most likely to be ‘1’ or ‘0’, as well as the numeric probability of the bin to be the least likely bin (which implies the numeric probability of the most likely bin as well) In the H.264 standard the probability estimation is performed by means of a finite-state machine with a table-based transition process between 64 different representative probability states {Pk|0≦k&lt;64} for the LPS probability pLPS. 
         [0010]    In the H.264 standard, the binarization mappings are either specifically defined or are obtained by a combination of four elementary binarization processes. The four elementary binarization processes are Unary binarization process, the Truncated Unary (TU) binarization process, the Concatenated Unary/K-th order Exp-Golomb (EGk) binarization process, and the Fixed-Length binarization process. For example, the DCT transform coefficient types have a binarization which is a combination of TU binarization and EGk binarization. In other words, a DCT transform coefficient is first partitioned into  2  syntax elements, each syntax element is binarized differently and then the binarizations are concatenated together. The first syntax element is binarized using the TU binarization process and is called a prefix, whereas the second syntax element is binarized using the EGk binarization process, and is called the suffix. 
         [0011]    Despite its higher coding efficiency, one main disadvantage of Arithmetic coding lies in its inherent sequential nature. The inherent sequential nature poses an even greater burden during decoding, where processing time is crucial and delays during decoding and displaying are unacceptable. The inherent sequential nature and the computational complexity hamper the adoption of CABAC in speed requiring devices and other processing devices. Keeping in view the fact that H.264 is expected to supersede all previous video coding standards, it may be appreciated that it would be desirable to develop systems that are capable of decoding the bitstream faster. 
         [0012]    U.S. Pat. No. 7,262,722 discloses a CABAC decoder with parallel binary arithmetic decoding which includes a first, second and third pairs of look-up tables and first, second and third multiplexers. The tables and multiplexers are used and controlled in common in order to decode a number of bits simultaneously. Nevertheless, the described system is fairly slow and depends on the number of lookup tables, meaning that in order to process more bits in parallel, more lookup tables and multiplexers are needed, which in return slow the process and increase the overall complexity and cost of the system. 
         [0013]    As stated above, one of the binarization processes is the TU binarization process. In order to execute the TU binarization process a cMax parameter, also known as the “cutoff” parameter, is required. The TU binarization process maps each syntax element&#39;s value, smaller than cMax, to a binary sequence consisting a number, equal to the element&#39;s value, of ‘1’s and a ‘0’ at the sequence&#39;s end. If the element&#39;s value is equal to cMax it is converted to a sequence having a number (equal to the element&#39;s value, i.e. the eMax value) of ‘1’s, without a ‘0’ at the end. Thus, for example, if cMax=4 and the syntax element&#39;s value is 3 then its corresponding TU binary sequence is ‘1110’ However, if cMax=4 and the syntax element&#39;s value is 4 then its corresponding TU binary sequence is ‘1111’. 
         [0014]    Another binarization process is the EGk binarization process. The EGk binarization process, as described in the H.264 standard, is more complex and can be shown as an output of the C++ microcode shown in  FIG. 1   a.  In the displayed microcode, ‘x’ is the value of the syntax element and ‘k’ is the order of the EGk. For example if x=“3” and k=0, then the EG 0  binary sequence is ‘11000’. Different types of syntax elements may belong to different ‘k’ orders. 
         [0015]      FIG. 1   b  depicts a table illustrating an example of the binarization of a DCT transform coefficient according to the H.264 standard. Before the transformation coefficients are binarized, each coefficient value is subtracted by “1”, for efficiency reasons, as the coefficient value of “0” is handled differently in the standard. The new “coefficient value−1” is referred to hereinafter as “Y”. In this example, for the TU prefix, the cMax=“14”. When the Y is less than 14, it is mapped to a TU binary sequence consisting of a continuation of ‘1’ bits and terminating with a ‘0’ bit. On the other hand, when the value of Y is larger or equal to 14, the prefix part, valued  14 , is mapped to a TU code, and the remaining suffix part, which is the Y value subtracted by the prefix value (i.e. “14”), is mapped to an EGk binary sequence having an order of “0” (k=0). An EGk binarization code having an order of 0 is referred to hereinafter as “EG 0 ”. Thus, different binarization processes are used depending on the magnitude of the coefficient&#39;s value, in order to adaptively apply higher probabilities to smaller values that occur more frequently in the binarization and significantly increase arithmetic coding efficiency. Thus, each coefficient value larger than “14” is mapped to a binary sequence which is a concatenated scheme derived from the TU and the EG 0  binarization processes. 
         [0016]    As stated in the H.264 standard, the compressed video elements are binarized, CAVLC or CABAC encoded, and packaged into the bitstream according to a pre-determined syntax order as defined in section 7.3 of the standard. The suffix binary sequence of the binarization of the DCT transform coefficient is processed and encoded into a bitstream as part of the residual syntax in section 7.3.5.3, Thus when the decoding machine receives a bitstream for decoding and displaying it can easily find the bits belonging to the suffix within the encoded bitstream by decoding the bitstream serially according to section 7.3 of the H.264 standard. 
         [0017]      FIG. 2  depicts a table showing an example of the suffix of the binarization of a DCT transform coefficient, as described in relations to  FIG. 1   b,  according to the H.264 standard. As shown the suffix has two parts, the first part which is referred to hereinafter as the “length” and second part which is referred to hereinafter as the “tail”. The length part, which is always terminated by ‘0’ indicates the length of the tail, where the number of ‘1’s in the sequence indicates the number of bits in the tail. For example, if the length sequence is ‘110’ the tail has “2” bins. As stated above in relations to  FIG. 1   b,  the x, in this case, is equal to Y−14. The binarized suffix length may be used in binarized form as shown in the table of  FIG. 2 , or in decimal form, according to the needs and requirements. 
         [0018]    More information may be found in the publication: “Context Based Adaptive Binary Arithmetic Coding in H.264/AVC Video Compression Standard” by Detlev Marpe, Heiko Schwarz and Thomas Wiegand, IEEE transactions on circuits and systems for video technology, Vol. 13, No. 7, July 2003. 
         [0019]      FIG. 3  depicts a generic decoding system used for decoding and displaying transmitted digital video contents. The bitstream source  100  may receive the video bitsreams over cable, through the internet, over the air, through terrestrial communication, or any other communication medium used for transmitting digital video signals. Once the bitstream source  100  receives the encoded video bitstreams its task is to timely feed these bitstreams into decoding system  220  for processing. At first, the decoding system  220  receives the encoded bitstreams and starts decoding them. During decoding some of the bitstreams are also decoded to their binarized sequences. The binarized sequences are then converted into their original syntax elements using the reverse binarization process. The syntax elements are then further processed into a video stream ready for display. The video stream is then sent from the decoding system  220  to display unit  300  for display. Inside the decoding system  220  lies the decoder circuit (not shown) which decodes the designated bitstreams into binarized sequences. The decoder circuit comprises a number of sub-decoders for processing different types of bitstreams. One of these sub-decoders is responsible for processing the bitstream belonging to the suffix. The essence of the invention lies in the implementation of the sub-decoder capable of parallel processing a number of bits in the bitstream belonging to the suffix length. 
         [0020]    The status of the arithmetic decoding engine is represented by a value codIOffset pointing into the code sub-interval and the corresponding range codIRange of that sub-interval. At the beginning of the decoding process, codIRange is set to  510 , codIOffset is set by reading 9 bits from the bitstream, as described in section 9.3.1.2 of the standard. Then for decoding of each single binary decision, the following two-step operation is employed: first, the related context model is determined according to the rules specified in section 9.3.3.1 of the standard, and then the binary decision is decoded as specified in section 9.3.3.2. As described in the H.264 standard, the bin can then be decoded using the regular or the bypass decoding process. 
         [0021]    As stated above in relations to  FIG. 2 , the suffix length indicates the number of bins in the tail, a trait which allows the calculation of the maximum possible length. In addition, as specified in section 9.3.2, table 9-25, the suffix length is decoded using the CABAC bypass decoding process as described in the H.264 standard. The CABAC encoder is using the bypass encoder process in conjunction with syntax elements that are uniformly distributed, for which the probability of the encoded bin being 0 or 1 is the same probability, and therefore the current interval is always divided in the encoder into two equal parts, and therefore each single bin is encoded by a single bit. The bypass decoding process is described in the H.264 standard section 9.3.2.3. For these binarization processes, the prefix and the suffix bit strings are separately indexed as specified in sub clause 9.3.3 of the H.264 standard. 
         [0022]      FIG. 4  is a flowchart illustrating the bypass decoding process for a single bit from the bitstream, as disclosed in section 9.3.3.2.3 of the H.264 standard. In step  1  three parameters are received: codIOffset, codIRange and a bit, all of which are deduced from the received bitstream. In step  2  the codIOffset bits are moved one space left (i.e. codIOffset is multiplied by two), and the bit of the bitstream is placed in the LSB of codIOffset. In step  3  the codIOffset value is compared to the codIRange value. If the codIOffset is smaller than the codIRange then the bin outcome is equal to ‘0’, however, if the codIOffset is larger or equal to the codIRange, then the bin outcome is equal to ‘1’ and codIRange is deduced from the codIOffset to generate the new codIOffset. In both cases the process for a single bin is finished in step  6 . The next bit may be processed accordingly with the new codIOffset. 
         [0023]      FIG. 5  is a flowchart illustrating the decoding process for the suffix length as derived from  FIG. 4  and according to the H.264 standard. In step  11  three parameters of the suffix are received: codIOffset, codIRange and the bitstream of the suffix. In step  12  the codIOffset bits are moved one space left (i.e. codIOffset is multiplied by two), and the first bit of the suffix bitstream is placed in the LSB of codIOffset. In stop  13  the codeIOffset value is compared to the codIRange value. If the codIOffset is larger or equal to the codIRange, then the first bin is equal to ‘1’, the new codIRange is deduced from the codIOffset, and steps  12 - 14  are repeated until the codIOffset is smaller than the codIRange. When the codIOffset is smaller than the codIRange then a bin equal to ‘0’ is added to the binstring effectively ending the process of decoding the suffix length binstring in step  16 . Nevertheless, as shown, the described decoding process has a sequential nature requiring revaluation of the codIOffset before each new bit can be processed, a trait which can cost precious processing time and burden the implementation of this process with many processing cycles which multiply as the number of bits required for process increase. 
         [0024]      FIG. 6  is a schematic diagram of a prior art implementation of the process described in relations to  FIG. 5 . Block  101  receives as input the codIOffset, codIRange and the first bit of the suffix bitstream. As described in relation to  FIG. 5 , the codIOffset bits are first moved one space left and the received first bit is added to codIOffset, in concatenator  201 . In other words, Bit 1  is concatenated to the codIOffset. The codIRange value is then subtracted from the concatenated codeIOffset value in subtractor  202 . If the result is positive, then the MUX  204  will output a “1”, and the MUX  203  will output the subtractor&#39;s  202  result as the new codIOffset. If the result is negative, then the MUX  204  will output a “0”, and the MUX  203  will output the concatenator  201  output. Blocks  102 ,  103  and  104  perform similarly to block  101 . Thus a number of blocks may be connected in order to process a number of bits. However, since each block waits for the codIOffset input from the last block, the total processing time equals to the total processing time of all the blocks added together. This sequential process requires a long processing time, especially when dealing with a big number of bits. For the sake of brevity the above description dealt with the processing of only 4 bits, however, in real decoding systems the suffix length decoder is sometimes required to process 16 bits. 
         [0025]    It is an object of the present invention to provide a system for decoding a number of bits in parallel using a minimal number of processing cycles. 
         [0026]    It is another object of the present invention to provide a hardware implementation for rapidly decoding a suffix length bitstream, according to the H.264 standard. 
         [0027]    It is still another object of the present invention to provide a system for parallel processing of all the suffix length bits. 
         [0028]    It is still another object of the present invention to provide a system capable of parallel processing of the suffix length bitstream for supplying the suffix length in a standard binary form. 
         [0029]    It is still another object of the present invention to provide a system capable of parallel processing of the suffix length bitstream for supplying a new codIOffset as required by the H.264 standard. 
         [0030]    Other objects and advantages of the invention will become apparent as the description proceeds. 
       SUMMARY OF THE INVENTION 
       [0031]    The present invention relates to a system for the parallel processing of a number of binstream bins comprising: (a) inputs for receiving the codIOffset, the codIRange and the bitstream suffix bits; (b) a first circuit for the parallel processing of said number of said bitstream suffix bits, said codIOffset, and said codIRange for producing an indication of the binstream suffix length magnitude; (c) a second circuit for the parallel processing of said number of said bitstream suffix bits, said codIOffset, and said codIRange for producing said number of speculative codIOffsets; (d) a third circuit for combining the products of said first circuit and the products of said second circuit for producing a new codIOffset; and (e) a fourth circuit for combining the products of said first circuit with said number of constants for producing a number indicative of the binstream suffix length. 
         [0032]    Preferably, the number of bitstream suffix bits is 16. 
         [0033]    In one embodiment, the binstream suffix length belongs to a syntax element of a DCT coefficient type. 
         [0034]    In another embodiment, the binstream suffix length belongs to a syntax element of a Motion Vector. 
         [0035]    Preferably, the system is also used for finding errors in the bitstream suffix bits. 
         [0036]    Preferably, the bitstream suffix bits are fed in a terraced form into the inputs. 
         [0037]    Preferably, the first circuit comprises: (a) inputs for receiving the codIOffset, the codIRange and said bitstream suffix bits; (b) at least one concatenator for concatenating at least one bit of said bitstream suffix to said codIOffset; (c) at least one multiplier for multiplying said codIRange by a preset constant; (d) at least one comparator for comparing products of said concatenator and said multiplier; and (e) at least one output for outputting at least one result of said at least one comparator. 
         [0038]    Preferably, the first circuit further comprises: (f) at least one inverter for inverting at least one output of said first circuit; and (g) at least one AND gate for logically ANDing at least two outputs of said first circuit. 
         [0039]    Preferably, the system is also used for finding errors, in the bitstream suffix bits, by finding that the outputs of the AND gates have more than one logical ‘1’. 
         [0040]    Preferably, the preset constant is equal to the result of the function (2 i+1 −1) where i is a whole number which starts from 0 for the first input and increases by 1 for each new input. 
         [0041]    Preferably, the bitstream suffix bits are fed in a terraced form into the inputs of the first circuit. 
         [0042]    Preferably, the second circuit comprises: (a) inputs for receiving the codIOffset, the codIRange and said bitstream suffix bits; (b) at least one concatenator for concatenating at least one bit of said bitstream suffix to said codIOffset; (c) at least one multiplier for multiplying said codIRange by a preset constant; (d) at least one subtracter for subtracting the product of said multiplier from said concatenator; and (e) at least one output for outputting at least one result of said at least one subtractor. 
         [0043]    Preferably, the bitstream suffix bits are fed in a terraced form into the inputs of the second circuit. 
         [0044]    Preferably, the preset constant is equal to the result of the function (2 i+1 −2) where i is a whole number which starts from 0 for the first input and increases by 1 for each new input. 
         [0045]    The present invention further relates to system for the parallel processing of a binstream suffix length in parts comprising: (a) inputs for receiving the codIOffset, the codIRange and the bitstream suffix bits; (b) a first circuit for the parallel processing of said number of said bitstream suffix bits, said codIOffset, and said codIRange for producing an indication of the binstream suffix length magnitude; (c) a second circuit for the parallel processing of said number of said bitstream suffix bits, said codIOffset, and said codIRange for producing said number of speculative codIOffsets; (d) a third circuit for combining the products of said first circuit and the products of said second circuit for producing a new codIOffset; (e) a fourth circuit for combining the products of said first circuit with said number of constants for producing a binstream suffix length; (f) a fifth circuit for subtracting said codIRange from the last output of the second circuit for producing a codIOffset ready for input for said first circuit and said second circuit of the next part; and (g) a sixth circuit for detecting if one of the outputs of said first circuit is a logical ‘1’. 
         [0046]    Preferably, the bitstream suffix bits are fed in a terraced form into the inputs. 
         [0047]    Preferably, the fifth circuit comprises: (a) an input for receiving the codIRange; (b) an input for receiving the last codIOffset output from the second circuit; (c) a subtractor for subtracting said codIRange from codIOffset; and (d) an output for outputting the result from said subtractor as a codIOffset for the next part of said parallel processing of said system. Preferably, the system is also used for finding errors in the bitstream suffix bits. 
         [0048]    Preferably, the sixth circuit is used for error detecting. 
     
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         [0049]    In the drawings: 
           [0050]      FIG. 1   a  is an example of a microcode for computing the suffix according to the H.264 standard, 
           [0051]      FIG. 1   b  depicts a table illustrating an example of the binarization of a DCT transform coefficient according to the H.264 standard. 
           [0052]      FIG. 2  depicts a table showing an example of the suffix of the binarization of a DCT transform coefficient according to the H.264 standard. 
           [0053]      FIG. 3  depicts a generic decoding system used for decoding and displaying transmitted digital video contents. 
           [0054]      FIG. 4  is a flowchart illustrating the bypass decoding process for a single bin from the bitstream according to the H.264 standard. 
           [0055]      FIG. 5  is a flowchart illustrating the decoding process for the suffix length. 
           [0056]      FIG. 6  is a schematic diagram of a prior art implementation of the processing of four suffix length bits. 
           [0057]      FIG. 7  is a block diagram of a hardware implementation of the simultaneous parallel processing of 4 bitstream suffix length bits, according to one embodiment. 
           [0058]      FIG. 8  is a block diagram of an implementation of a codIOffset speculation circuit, according to an embodiment of the invention. 
           [0059]      FIG. 9  is a block diagram illustrating the combination of the 4-bin processing circuit with the 4-bin speculation circuit, according to an embodiment of the invention. 
           [0060]      FIG. 10  is a block diagram illustrating an implementation of a function for combining bits, according to an embodiment of the invention. 
       
    
    
     DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS 
       [0061]    The following terms are described explicitly: 
         [0062]    Bitstream—a sequence of bits that forms the representation of coded pictures and associated data forming one or more coded video sequences, which is encoded by the encoding system, according to the H.264 standard. The bitstream may be received over cable, through the internet, over the air, through terrestrial communication, or any other communication medium used for transmitting digital signals. 
         [0063]    Syntax Element—an element of data represented in the bitstream. Different Syntax Elements can represent different types of data (e.g. motion vectors, DCT coefficients, etc.) 
         [0064]    Bin—a binary digit, which is the binary decision of the arithmetic decoder. 
         [0065]    Bin string—a string of bins, which is an intermediate binary representation of a value of a syntax element. 
         [0066]    Binstream—a sequence of bin strings. The bitstream is converted to a binstream using the H.264 CABAC decoding process as defined in the standard. 
         [0067]    Binarization—a bin string representing a value of a syntax element. 
         [0068]    Binarization process—a unique mapping process of a syntax element&#39;s value onto a bin string. 
         [0069]    codIOffset,—a 9 bits state variable of the arithmetic decoding engine, pointing into the code sub-interval. 
         [0070]    codIRange—a 9 bit state variables of the arithmetic decoding engine, representing the range of the code sub-interval. 
         [0071]    encoded bitstream—a bitstream, binarized (using the binarization process) and encoded by the encoding system, according to the H.264 standard, 
         [0072]    Binarized suffix length—as described in relations to  FIG. 1   a,    FIG. 1   b  and  FIG. 2 . 
         [0073]    Binstream suffix—the next bins, of the encoded binstream, located after the bins processed as the prefix of the syntax element. 
         [0074]    Bitstream suffix—the next bits, of the encoded bitstream, located after the bits processed as the prefix of the syntax element, and used for decoding the binstream suffix. In the bypass decoding process, a single bit from the bitstream is processed each time for decoding a single bin. 
         [0075]      FIG. 7  is a block diagram of a hardware implementation of the simultaneous parallel processing of 4 binstream suffix length bins, according to one embodiment. For the sake of brevity the following description deals with an implementation capable of processing 4 bins, although the invention may be implemented for other desirable numbers of bins. The input parameters of the circuit  200  are the CABAC arithmetic decoder state variables codIOffset, codIRange and the first 4 bits of the suffix part of the received bitstream, labeled Bit 1 , Bit 2 , Bit 3 , and Bit 4 , where Bit 1  is the next bit in the ordered encoded bitstream after the prefix. All these parameters are retrieved from the encoded bitstream. At first, Bit 1  from input  301  is concatenated to the right end (i.e. to the LSB) of codIOffset sequence from input  302  using concatenator  303 . The concatenation process is very fast in terms of processing time, and mathematically it is equivalent to multiplying the codIOffset by “2” and adding Bit 1 . At the same time, CodIRange from input  307  is multiplied, using multiplier  305 , by a constant of 1, stored in buffer  306 . The concatenated result from concatenator  303  and the multiplied result from multiplier  305  are compared by comparator  304 . If the result from concatenator  303  is larger or equal to the multiplied result from multiplier  305  then comparator  304  produces a ‘1’, otherwise, comparator  304  produces a ‘0’. The produced result of comparator  304  is then inverted by inverter  308  and sent to output  309 . The bit from output  309  is referred to hereinafter as Z 1 . Simultaneously to the above described process, Bit 1  and Bit 2  from input  401  are processed similarly by the components  403 - 406  which function as components  303 - 306  respectively, excluding the constant in buffer  406  which is a “3”. The concatenation process of concatenator  403  is mathematically equivalent to multiplying the codIOffset by “2”, adding Bit 1 , multiplying the result by “2” and adding Bit 2 . The produced result of comparator  404  is then inverted, and a logical AND operation is done with the result of comparator  304 , by the “AND” logic gate  408 , and the outcome is sent to output  409 . The bit from output  409  is referred to hereinafter as Z 2 . The other two inputs: from input  501  (3 bits: Bit 1 , Bit 2 , and Bit 3 ) and from input  601  (4 bits: Bit 1 , Bit 2 , Bit 3 , and Bit 4 ), are also processed similarly by components  503 - 506  and  603 - 606  respectively. Components  503 - 506  function similarly to components  403 - 406  respectively, excluding the constant in buffer  506  which is a 7, and components  508 - 509  function similarly to components  408 - 409 , where the bit from output  509  is referred to hereinafter as Z 3 . Components  603 - 606  function similarly to components  403 - 406  respectively, excluding the constant in buffer  606  which is a 15, and components  608 - 609  function similarly to components  408 - 409 , where the bit from output  609  is referred to hereinafter as Z 4 . Thus the system processes the 4 terraced inputs separately and simultaneously, for producing a total outcome of 4 bits labeled Z 1 -Z 4 . By terraced inputs it is meant to include the first input that is a single bit and the other inputs which are each a concatenation of single bit of a prior input. The constants required for storage in buffers  306 ,  406 ,  506 , and  606  can be derived using this function: 
         [0000]      Const=2 i+1 −1 
         [0000]    where i is a whole number which starts from 0 for the first input and increases by 1 for each new input. Since all the constants are known before implementation, they may be hardwired in the system  200  during fabrication. 
         [0076]    For the sake of brevity an example is set forth for demonstrating the process of circuit  200  as described in relations to  FIG. 7 . In this example, codIOffset=“400” and codIRange=“500” and the first 4 bits of the suffix part of the received bitstream are: Bit 1 =‘1’, Bit 2 =‘1’, Bit 3 =‘0’, and Bit 4 =‘0’. Concatenator  303  concatenates Bit 1  to the codIOffset which produces “801”. Multiplier  305  produces the codIRange multiplied by “1” which is “500”. Comparator  304  produces a ‘1’ which is inverted by inverter  308 , effectively achieving Z 1 =‘0’. Concatenator  403  concatenates Bit 1  and Bit 2  to the codIOffset which produces “1603”. Multiplier  405  produces the codIRange multiplied by “3” which is “1500”. Comparator  404  produces a ‘1’ which is inverted and logically ANDed with the result from comparator  304 , effectively achieving Z 2 =‘0’. Concatenator  503  concatenates Bit 1 , Bit 2  and Bit 3  to the codIOffset which produces “3206”. Multiplier  505  produces the codIRange multiplied by “7” which is “3500”. Comparator  504  produces a “0” which is inverted and logically ANDed with the result from comperator  404 , effectively achieving Z 3 =‘1’. Concatenator  603  concatenates Bit 1 , Bit 2 , Bit 3  and Bit 4  to the codIOffset which produces “6412”. Multiplier  605  produces the codIRange multiplied by “15” which is “7500”. Comparator  604  produces a ‘0’ which is inverted and logically ANDed with the result from comperator  504 , effectively achieving Z 4 =‘0’. 
         [0077]    The implementation described in relations to  FIG. 7  is designed so that for a proper standardized encoded bitstream of a suffix, only one of the bits labeled Z 1 -Z 4  is a ‘1’, and the rest are ‘0’, where the location of the ‘1’ indicates the magnitude of the binarized suffix length. 
         [0078]      FIG. 8  is a block diagram of an implementation of a codIOffset speculation circuit, according to an embodiment of the invention. For the sake of brevity the following description deals with the parallel processing of 4 bins, although the system may be configured to process other numbers of bins. The input parameters of the circuit  700  are the codIOffset, codIRange and the first 4 bits of the suffix part of the bitstream, labeled Bit 1 , Bit 2 , Bit 3 , and Bit 4 . At first, Bit 1  from input  701  is concatenated to the right end (i.e. to the LSB) of codIOffset sequence from input  702  using concatenator  703 . The concatenation process is very fast in terms of processing time, and mathematically equivalent to multiplying the codIOffset by “2” and adding Bit 1 . At the same time CodIRange from input  707  is multiplied by a constant of “0”, stored in buffer  706 , using multiplier  705 . The result from multiplier  705  is then subtracted from the concatenated result from concatenator  703 , by subtractor  704 . The produced result of subtractor  704  is then sent to output  708 . Output  708  is designed as a 9-line bus for carrying the resulting bits from subtractor  704 , therefore, if the resulting bits are more than 9 bits, only the 9 LSB bits are sent to output  708 . Simultaneously to the above described process, Bit 1  and Bit 2  from input  711  are processed similarly by the components  713 - 716  which function as components  703 - 706  respectively, excluding the constant in buffer  716  which is a “2”. The concatenation process of concatenator  713  is mathematically equivalent to multiplying the codIOffset by “2”, adding Bit 1 , multiplying the result by “2” and adding Bit 2 . The produced result of subtractor  714  is then sent to output  718 , which is similar to output  708 . The other two inputs: from input  721  (three bits: Bit 1 , Bit 2 , and Bit 3 ) and from input  731  (four bits: Bit 1 , Bit 2 , Bit 3 , and Bit 4 ), are also processed similarly by components  723 - 726  and  733 - 736  respectively. Components  723 - 726  and  728  function similarly to components  703 - 706  and  708  respectively, excluding the constant in buffer  726  which is a “6”. Components  733 - 736  and  738  function similarly to components  703 - 706  and  708  respectively, excluding the constant in buffer  736  which is a “14”. Thus the system processes the 4 terraced incomes separately and simultaneously, for producing a total outcome of 4 streams of 9 bits each. These 4 outcome streams of 9 bits each are 4 possible new codIOffsets. Although for the sake of time saving, all the 4 possible new codIOffsets have been produced, however, only one of these codIOffsets will eventually be selected as the codIOffset outcome of the system (described below in relations to  FIG. 9 ). The Constants required for storage in Const  706 ,  716 ,  726 , and  736  can be derived using a simple function: 
         [0000]      Const=2 i+1 −2 
         [0079]    where i is a whole number which starts from 0 for the first input and increases by 1 for each new input. Since all the constants are known before implementation, they may be hardwired in the system  700  during fabrication. 
         [0080]    For the sake of brevity an example is set forth for demonstrating the process of circuit  700  as described in relations to  FIG. 8 . Continuing the example disclosed above in relation to  FIG. 7 , codIOffset=“400” and codIRange=“500” and the first 4 bits of the suffix part of the received bitstream are: Bit 1 =‘1’, Bit 2 =‘1’, Bit 3 =‘0’, and Bit 4 =‘0’. Concatenator  703  concatenates Bit 1  to the codIOffset which produces “801”. Multiplier  705  produces the codIRange multiplied by “0” which is “0”. Subtractor  704  produces the result “801” over bus  708 , however, since bus  708  carries only the 9 LSB bits, the carried result over bus  708  is “289”. It should be mentioned that a result having more than 9 bits is not possible according to the H.264 standard anyway and this result of more than 9 bits will be discarded by the other circuits of the invention in due course. 
         [0081]    Concatenator  713  concatenates Bit 1  and Bit 2  to the codIOffset which produces “1603”. Multiplier  715  produces the codIRange multiplied by 2 which is “1000”. Subtractor  714  produces the result “603”, which is carried over the 9 bit bus  718  as “91”. Concatenator  723  concatenates Bit 1 , Bit 2  and Bit 3  to the codIOffset which produces “3206”. Multiplier  725  produces the codIRange multiplied by 6 which is “3000”. Subtractor  724  produces the result “206” over bus  728 . Concatenator  733  concatenates Bit 1 , Bit 2 , Bit 3  and Bit 4  to the codIOffset which produces “6412”. Multiplier  735  produces the codIRange multiplied by 14 which is “7000”. Subtractor  734  produces the result “−588”, which is carried over the 9 bit bus  738  as “436”. 
         [0082]      FIG. 9  is a block diagram illustrating the combination of the 4-bit processing circuit  200  of  FIG. 7  with the 4-bit speculation circuit  700  of  FIG. 8 , according to an embodiment of the invention. For the sake of brevity the following description deals with the parallel processing of 4 bins, although the system may be configured to process other numbers of bins. As shown, the circuit  200  outputs are combined twice, once, in block  900 , with known constants for producing the binstream suffix length, and once, in block  800 , with the speculation circuit  700  outputs for producing the new codIOffset. The combination of inputs in block  900  will be described later in detail in relations to  FIG. 10 , however, the function of block  900  may be understood as a mathematical equivalent of multiplication and adding. The multiplication is between the set constants, i.e. stored in buffers  909 ,  919 ,  929 ,  939 , and Z 1 -Z 4 , respectively, and the adding is the logical adding of all these multiplication results. As described in relations to  FIG. 7  only one of the bits in Z 1 -Z 4  is expected to be a ‘1’ therefore only one of the constants will be outputted from block  900 . Similarly, the speculated codIOffsets, i.e. outputs on buses  708 ,  718 ,  728 , and  738 , are also combined in block  800 , like in block  900 , for effectively outputting only one of them as the new codIOffset. 
         [0083]    For the sake of brevity the example described in relations to  FIG. 7  and  FIG. 8  is continued in relations to  FIG. 9 . As described Z 1 =‘0’, Z 2 =‘0’, Z 3 =‘1’, and Z 4 =‘0’. Bus  708  carries “289”, bus  718  carries “91”, bus  728  carries “206”, and bus  738  carries “436”. Therefore, when multiplying Z 1  with ‘00’ from buffer  909 , the result is “0”. When multiplying Z 2  with ‘01’ from buffer  919 , the result is “0”. When multiplying Z 3  with ‘10’ from buffer  929 , the result is ‘10’, meaning a decimal “2”. When multiplying Z 4  with ‘11’ from buffer  939 , the result is “0”. After adding all these results the combined outcome is a decimal “2” (i,e. a binary ‘10’). Similarly, when multiplying Z 1  with “289” from bus  708 , the result is “0”. When multiplying Z 2  with “91” from bus  718 , the result is “0”. When multiplying Z 3  with “206” from bus  728 , the result is “206”. When multiplying Z 4  with “436” from bus  738 , the result is “0”. After adding all these results the combined outcome is “206”, which is the new codIOffset. 
         [0084]      FIG. 10  is a block diagram illustrating an implementation of a function for combining bits, according to an embodiment of the invention. The system  900  inputs  903 ,  913 ,  923 , and  933  receive Z 1 -Z 4  respectively. The other inputs receive constants in a binary progressive sequence, where inputs  901 - 902  receive ‘00’, input  911 - 912  receive ‘01’ respectively, inputs  921 - 922  receive ‘10’ respectively, and inputs  931 - 932  receive ‘11’. For the sake of brevity, only elements  901 - 905  will be described, the other corresponding elements function in similarly the same way. When Z 1  is received from input  903  it is sent to AND gate  904  and AND gate  905 . In AND gate  904  it is logically ANDed with the bit from input  901 , e.g. the ‘0’ bit. In AND gate  905  it is logically ANDed with the bit from input  902 , e.g. the ‘0’ bit. Elements  911 - 915 ,  921 - 925 , and  931 - 935  function similarly as elements  901 - 905  respectively, where some of the input bits vary accordingly. The results from AND gates  904 ,  914 ,  924 , and  934  are all entered to OR gate  951  and the result is transferred to output  952 . Similarly, the results from AND gates  905 ,  915 ,  925 , and  935  are all entered to OR gate  961  and the result is transferred to output  962 . The results of outputs  952  and  962  are concatenated, where the result of output  952  is the MSB, for producing the value of the suffix length. 
         [0085]    For the sake of brevity the example described in relations to  FIG. 7 ,  FIG. 8  and  FIG. 9  is continued in relations to  FIG. 10 . As described Z 1 =‘0’, Z 2 =‘0’, Z 3 =‘1’, and Z 4 =‘0’. Therefore the outputs of AND gates  904 ,  905 ,  914 ,  915 ,  925 ,  934 , and  935  is ‘0’, and only AND gate  924  outputs ‘1’. OR gate  951  outputs a ‘1’ and OR gate  961  outputs a ‘0’ effectively outputting together a binary sequence ‘10’ (i.e. a decimal “2”). 
         [0086]    Block  800  described in  FIG. 9  functions similarly to block  900  described in relations to  FIG. 10 . The outputs on connecting buses are combined with the Z 1 -Z 4  each. Meaning that the output on bus  708  is combined with Z 1  from  309 , the output on bus  718  is combined with Z 2  from  409 , the output on  728  is combined with Z 3  from  509 , and the output on bus  738  is combined with Z 4  from  609 . In block  800  the received Z 1  is sent to 9 AND gates. The 9 bits received from bus  708  are sent each to one of these 9 AND gates. Similarly, the bits from bus  718  are each logically ANDed with the received Z 2 , the bits from bus  728  are each logically ANDed with the received Z 3 , and the bits from bus  738  are each logically ANDed with the received Z 4 . The results of the AND gates processing the first bits of the outputs received from all the buses are entered into a first OR gate. Similarly, the results of the AND gates processing the second bits received from all the buses are entered into a second OR gate, and so on until the processing of all the ninth bits. The results of all the 9 OR gates are outputted as the new codIOffset. 
         [0087]    In a preferred embodiment, the above described implementation of  FIG. 7 ,  FIG. 8 ,  FIG. 9 , and  FIG. 10 , is used for decoding 16 suffix bits from an encoded bitstream. The circuit  200  is designed to receive 16 terraced inputs, starting from the first bit as the first input continuing with the first two bits as second input and concluding with all the 16 bits as the sixteenth input. The circuit  200  constants are (in ascending order): {1, 3, 7, 15, 31, 63, 127, 255, 511, 1023, 2047, 4095, 8191, 16383, 32767, and 65553}, respectively. Similarly, the circuit  700  is designed to receive 16 terraced inputs, starting from the first bit as the first input continuing with the first two bits as second input and concluding with all the 16 bits as the sixteenth input. The circuit  700  constants are (in ascending order): {0, 2, 6, 14, 30, 62, 126, 254, 510, 1022, 2046, 4094, 8190, 16382, 32766, and 65534}, respectively. The set constants for inputting into block  900  are 0-15 in binary form, i.e. {0000, 0001, 0010 . . . 1111}. 
         [0088]    In one of the embodiments, the described invention may be used for error finding. As described in relations to  FIG. 7  and  FIG. 9 , the outputs of circuit  200  Z 1 -Z 4  are designed so that for a proper standardized encoded bitstream of a suffix only one of the bits labeled Z 1 -Z 4  is a ‘1’, and the rest are ‘0’. Therefore, an error detecting circuit may be added for detecting that if more than one of the labeled Z 1 -Z 4  is a ‘1’ or if none of the labeled Z 1 -Z 4  is a ‘1’ an error is declared. 
         [0089]    In one of the embodiments, the invention may be used for processing the length of the bitstream suffix in parts. The number of bitstream suffix bits may be partitioned into clusters of suffix bits, where each cluster is processed separately. The first cluster may be processed as described in relation to  FIG. 9 . At the outputs of block  200  a circuit is added for checking if a ‘1’ was outputted in one of the outputs Z 1 -Z 4 . If a ‘1’ is present on one of the Z 1 -Z 4  outputs, then the decoding is finished. However, if all Z 1 -Z 4  outputs are ‘0’ then the system continues processing the next cluster. The next cluster may also be processed as described in relation to  FIG. 9  apart from the input codIOffset which is the output from the last bus of block  700  (e.g. bus  738  in  FIG. 8  and  FIG. 9 ), of the first cluster, minus the codIRange. Thus the system may continue processing the clusters until a ‘1’ is received from the outputs of circuit  200 . For example, an 8 bit encoded bitstream suffix is requested for decoding on the 4-bit system described in relation  FIG. 9 . At start, the first 4 bits are processed as described in relation  FIG. 9 . Next, the output of bus  738  is read and the codIRange is subtracted from it. The result is then fed as the codIOffset, into circuit  200  and circuit  700 , for the next 4 bits, which are processed as described in relation  FIG. 9  with the new codIOffset. In one of the embodiments the maximum number of bitstream suffix length bits is known and therefore, if after processing all the clusters of suffix length bits all the outputs of all the cluster processing steps of circuit  200  are ‘0’, then an error is declared. In another embodiment the maximum number of bitstream suffix length bits is unknown and therefore, the processing continues until one of the outputs of circuit  200  is a ‘1’. 
         [0090]    In one embodiment the system of the invention may be used for syntax elements of DCT coefficients type. These syntax elements use a k=0, which require the binstream suffix to belong to the EGO binarization process, with a cMax=“14”. In another embodiment the system of the invention is used for syntax elements of Motion Vectors type. These syntax elements use a k=3, which require the binstream suffix to belong to the EG 3  binarization process, with a cMax=“9”. As described, the invention may be used to process any bitstream suffix bits of any syntax element as long as the suffix bits are decoded using the bypass mode as stated in the standard, and as long as the decoded bin string of the suffix length terminates in a ‘0’. 
         [0091]    While some embodiments of the invention have been described by way of illustration, it will be apparent that the invention can be carried into practice with many modifications, variations and adaptations, and with the use of numerous equivalents or alternative solutions that are within the scope of persons skilled in the art, without departing from the invention or exceeding the scope of claims.