Abstract:
A mechanism for efficient CAVLC coding in a hardware implementation of a H.264 coder is provided. In an embodiment of the present invention, multiple modular CAVLC engines that each process one sub-macroblock of data are used. An assembler engine that combines the CAVLC-encoded sub-macroblock data from each modular CAVLC engine to form a output bit-stream is also provided.

Description:
FIELD OF THE INVENTION 
     The present invention relates generally to digital video signal processing, and more specifically to devices for video coding. 
     BACKGROUND OF THE INVENTION 
     Video coding standards that make use of several advanced video coding tools and techniques to provide high compression performance are well known in the art. In the past, standards such as MPEG-2, MPEG4, and H.263 have been widely adopted. More recently, H.264 has been widely adopted as it offers better compression performance than other video compression standards. At the core of all these video compression standards are the techniques of motion compensation and transform coding. A diagram illustrating the operational blocks of a video encoder that conforms to the H.264 standard is shown in  FIG. 1 . 
     Motion compensation schemes basically assume, for most sequences of video frames, the amount of change from one frame to the next is small. Thus, compression can be achieved by transmitting or storing information in a frame as a difference, or delta, from a previous frame, rather than as an independent image. In this way, only the changes between a new frame and a previous frame need to be captured. The frame used for comparison is called a reference frame. 
     The specific type of motion compensation schemes used by many video encoding standards, such as H.264 AVC, is called block motion compensation. Block motion compensation schemes typically decompose a frame into macroblocks where each macroblock contains 16×16 luminance values (Y) and two 8×8 chrominance values (Cb and Cr), although other block sizes are also used. These macroblocks are typically processed one at a time. The compression mechanism in a video encoder would attempt to find a macroblock in the reference frame that closely matches the current macroblock of the current frame (motion estimation), and the differences between these two blocks would be transformed and quantized. The transform of a macroblock converts the pixel values of the block from the spatial domain into a frequency domain for quantization. This transformation step may use a two-dimensional discrete cosine transform (DCT) or other transformation methods. 
     The residual macroblock data generated by the transformation step is then quantized, and then coded by using variable length coding. In H.264, a Context Adaptive Variable Length Coding (CAVLC) scheme or a Context Adaptive Binary Arithmetic Coding (CABAC) scheme can be used for the variable length coding step. 
     For low-latency H.264 baseline-profile video encoding hardware device (e.g., a mobile phone having wireless video transmission capability, or a security camera), it is desirable to execute CAVLC coding at least as quickly as other stages of the encoder. 
     SUMMARY OF THE INVENTION 
     The present invention provides a mechanism for efficient CAVLC coding in a hardware implementation of a H.264 encoder. More specifically, in an embodiment of the present invention, multiple modular CAVLC engines that each process one sub-macroblock (or sub-block) of data are used. An assembler engine that combines the CAVLC-encoded data from each modular CAVLC engine to form a output bit-stream is also provided. 
     In one embodiment, a content-adaptive variable length coder of the present invention includes a plurality of variable length coding engines, where each variable length coding engine processes one sub-block of data at a time. Since multiple variable length coding engines are used, multiple sub-blocks of data are processed in parallel. The outputs of the variable length coding engine are called “variable length coded data sets” herein, where one data set is generated for each sub-block of data. In one embodiment of the invention, each variable length coding engine has its own buffer for storing the variable length coded data sets it produces. 
     The content-adaptive variable length coder of the present invention further includes an assembler circuit for assembling or “stitching” the data from the variable length coding engines together to form a bitstream. In one embodiment, the assembler circuit retrieves data of one variable length coded data set from one of the buffer and stores the data in an output buffer. Then, the assembler circuit retrieves data of another variable length coded data set from another one of the buffer and stores the data in the output buffer, right after the first data set. In one embodiment of the invention, the order (or sequence) in which the assembler circuit accesses the buffers (and the order in which the variable length data sets are stored in the output buffer) is pre-determined and may depend on the specific variable length coding algorithm that the VLC coder is designed to implement. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
       The invention will now be described with reference to the accompanying drawings which illustrate various example embodiments of the invention. Throughout the description, similar reference names may be used to identify similar elements. 
         FIG. 1  depicts a block diagram of a typical video encoder. 
         FIG. 2A  depicts sub-macroblocks that are assigned to a plurality of various CAVLC engines of the CAVLC of  FIG. 2B . 
         FIG. 2B  depicts a block diagram of a CAVLC coder according to an embodiment of the present invention. 
         FIG. 3  depicts data of a pre-assembler buffer according to an embodiment of the present invention. 
         FIG. 4  depicts a flow diagram of the operations of the assembler according to an embodiment of the invention. 
     
    
    
     DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS 
     The present invention provides a CAVLC coder that is implemented as a functional unit of a video encoder integrated circuit such as one compliant with H.264. For the purpose of elaborating the operations of the CAVLC coder of the present invention, residual data corresponding to a macroblock (which may be obtained after transformation and quantization) is depicted in  FIG. 2A . As shown, the residual data, like the macroblock data from which it is derived, is organized into 16×16 luminance residual values, and two 8×8 chrominance residual values. Further, the residual data is organized into sub-macroblocks (or sub-blocks) each containing 4×4 values in  FIG. 2A . 
     Also illustrated in  FIG. 2A , for purposes of elaboration, each sub-block is given a label—a 0 , b 0 , c 0 , a 1 , b 1 , c 1 , a 2 , b 2 , etc. These labels identify the specific VLC engines (described further below) that will process the sub-blocks, and an order in which the sub-blocks would be processed. It should be noted that sub-blocks are assigned to the VLC engines according to a specific VLC algorithm that the CAVLC coder  210  is designed to implement. In an actual implementation, the sub-blocks may not be assigned to the VLC engines in a manner as illustrated. 
     Attention now turns to  FIG. 2B , which is a block diagram of a CAVLC coder  210  according to an embodiment of the invention. As shown, the CAVLC coder  210  includes multiple modular VLC engines  212   a ,  212   b  and  212   c . In accordance with an embodiment of the invention, each VLC engine  212  is responsible for processing certain pre-determined sub-blocks. For instance, VLC engine  212   a  is responsible for processing sub-blocks a 0  to a 7 ; VLC engine  212   b  is responsible for sub-blocks b 0  to b 7 , and VLC engine  212   c  is assigned sub-blocks c 0  to c 7 . 
     It should be noted that the VLC engines  212   a - 212   c  each encode one sub-block of data at a time, although the VLC engines  212   a - 212   c  may be encoding data at the same time (e.g., in parallel). That is, VLC engine  212   a  would process sub-block a 1 , and then a 2 , and then a 3 , and so on, while VLC engine  212   b  would process sub-block b 1 , and then b 2 , and then b 3 , and so on. Depending on the architecture of the input buffer (not shown) that feeds data to the VLC engines  212   a - 212   c , one VLC engine may have to stall and wait for another engine to finish before it can process another sub-block. 
     According to another embodiment of the invention, a load balancing mechanism may be implemented in the CAVLC coder  210  such that stalling of the VLC engines  212   a - 212   c  can be minimized. However, while there are advantages to such mechanisms, the complexity the CAVLC coder  210  would be increased. In another embodiment of the invention, more than three VLC engines can be used to encode sub-block data in parallel. In another embodiment, two VLC engines may be used. 
     Outputs from the VLC engines  212   a - 212   c  are called variable length coded data sets, where each data set corresponds to a sub-block a 0  to c 7 . With reference still to  FIG. 2B , the VLC engines  212   a - 212   c  are coupled to provide the variable length coded data sets to pre-assembler buffers  214   a - 214   c , respectively. The pre-assembler buffers  214   a - 214   c  are coupled to assembler circuit  216  and output buffer  218 . After accessing the data sets in the pre-assembler buffers  214   a - 214   c , the assembler circuit  216  stores the data sets in the output buffer  218  in a pre-determined order. 
     CAVLC coder  210  further includes a header generation unit  211  that receives data such as motion vectors from other functional units of a video coder, and generates header data for each macroblock of CAVLC coded residual data. The header generation unit  211  is coupled to header buffer  213 , which stores header data produced by the header generation unit  211 . The assembler circuit  216  also accesses the header buffer  213  and stores appropriate header information into the output buffer. Data stored in the output buffer  218 , which may be implemented as a First-In-First-Out (FIFO) buffer, can be sequentially read out therefrom to form a bitstream that is compliant with H.264 AVC. 
     In one embodiment of the invention the pre-assembler buffers  214   a - 214   c  may be implemented as FIFO buffers as well.  FIG. 3  depicts contents of a pre-assembler buffer  214   a  in accordance with an embodiment of the present invention. As shown, pre-assembler buffer  214   a  is a 38-bit wide FIFO buffer. Thirty-two bits of each entry of the FIFO buffer are for storing variable length coded data sets produced by VLC engine  212   a . Five-bits of each entry of the FIFO buffer are for storing a value COUNT, which indicates how many bits of data in a data set are stored in the corresponding entry. For example, if an entry contains only ten bits of data (with twenty-two bits of junk data denoted in  FIG. 3  as “x”), the value of COUNT would be “10”. If an entry is occupied by thirty-two bits of data, the value of COUNT would be “32”. At least one bit of each entry of the FIFO buffer is for storing a value ID_FLAG, which indicates whether the entry contains variable length coded data or an identifier that identifies a particular variable length coded data set. 
     In the example illustrated in  FIG. 3 , if the entry has an ID_FLAG value 0, it may indicate variable length coded data are stored in the entry; and if the entry has an ID_FLAG value 1, it may indicate that the data stored in the entry is an identifier that identifies a particular sub-block (e.g., sub-block a 1 ). Entries having variable length coded data and following an entry having an ID_FLAG value of 1 are considered to be in the same variable length coded data set. It should be noted that each entry contains data from one variable length coded data set. As mentioned earlier, if data from one variable length coded data set does not occupy the entire data field of the entry, the rest of the data field will contain “junk data.” In one embodiment of the invention, a five-bit value is used as an identifier such that each variable length coded data set may be uniquely mapped to a sub-block (e.g., a 0  to c 7 ). Note that having the sub-block ID in the pre-assembler buffers enables the assembler to find the next sub-block to process without prior knowledge of which VLC engine processes which sub-block. This allows a load balancer, in some embodiments of the invention, to arbitrarily assign sub-blocks to VLC engines without adversely impacting the operation of the assembler. 
     Pre-assembler buffers  214   b  and  214   c  are similar to pre-assembly buffer  214   a , but they are configured to receive data from VLC engines  212   b  and  212   c , respectively. Header buffer  213  may be 37-bit wide for storing thirty-two bits of header data, and five bits of COUNT value to indicate how many bits of actual header data are stored in each entry. In one embodiment of the invention, the output buffer  218  is 32-bit wide. Header data may have a variable length as well. Therefore, in the present embodiment, a COUNT value is used to indicate a last bit of the header data. 
     With reference now to  FIG. 4 , a flow diagram  400  of certain operations of the assembler circuit  216  is depicted. At step  412 , the assembler circuit  216  accesses the header generator unit (not shown) to obtain header data for a macroblock, and stores the header data in the output buffer  218 . 
     Then, at step  414 , the assembler circuit  216  scans pre-assembler buffers  214   a - 214   c  to identify which buffer holds the data for the first sub-block, which is sub-block a 0 . At step  416 , the assembler circuit  216  then stores the variable length coded data corresponding to sub-block a 0  (excluding COUNT and ID_FLAG) in the output buffer  218 . Since data may be read out sequentially from the output buffer  218  to form a H.264 compliant bitstream, it is important to make sure that there are no “skipped bits” or “junk data” between the header data and the first variable length coded data set, and between subsequent variable length coded data sets. In one embodiment of the invention, the assembler circuit  216  shifts the variable length coded data by the same number of bits as indicated by the COUNT value in the last entry of the header data before storing the variable length coded data in the output buffer  218 . 
     At step  418 , the assembler circuit  216  scans pre-assembler buffers  214   a - 214   c  to identify which buffer holds the data for the second sub-block, which is sub-block b 0 . At step  420 , the assembler circuit  216  then stores the variable length coded data corresponding to sub-block b 0  (excluding COUNT and ID_FLAG) in the output buffer  218 . As in step  416 , the assembler circuit  216  shifts the variable length coded data corresponding to sub-block b 0  by the same number of bits as indicated by the COUNT value in the last entry for sub-block a 0 , thus ensuring that there is no “gap” between last bit of sub-block a 0  and the first bit of sub-block b 0 . 
     At step  422 , the assembler circuit  216  scans pre-assembler buffers  214   a - 214   c  to identify which buffer holds the data for the first sub-block, which is sub-block c 0 . At step  424 , the assembler circuit  216  then stores the variable length coded data corresponding to sub-block c 0  (excluding COUNT and ID_FLAG) in the output buffer  218 . As in steps  416  and  420 , the assembler circuit  216  shifts the variable length coded data corresponding to sub-block c 0  by the same number of bits as indicated by the COUNT value in the last entry for sub-block b 0 , thus ensuring that there is no “gap” between last bit of sub-block b 0  and the first bit of sub-block c 0 . 
     According to an embodiment of the invention, at step  426 , steps  412  to  424  are repeated for VLC coded data corresponding to sub-blocks a 1 , b 1 , c 1 , a 2 , b 2 , c 2 , a 3 , b 3 , c 3 , etc., until all the VLC coded data for the macroblock are stored in the output buffer  218 . This process is then repeated for another macroblock until an entire frame is coded. 
     In this way, by using multiple instances of VLC engine and an assembler circuit to “stitch” the outputs back into a bitstream, residual data can be efficiently coded using a CAVLC algorithm. 
     Embodiments of the invention have thus been disclosed. The foregoing descriptions of specific embodiments of the invention are presented for purposes of illustration and explanation. The embodiments were chosen and described in order to best explain the principles of the invention and its practical applications, to thereby enable others skilled in the art to best utilize the invention. They are not intended to be exhaustive or to limit the invention to the precise forms disclosed. Various modifications may occur to those skilled in the art having the benefit of this disclosure without departing from the inventive concepts described herein. In other instances, well known structures and devices have not been illustrated or described in detail in order to avoid obscuring aspects of the invention. It is the claims, not merely the foregoing illustration, that are intended to define the exclusive rights of the invention. 
     Furthermore, throughout this specification (including the claims), unless the context requires otherwise, the word “comprise”, or variations such as “comprises” Or “comprising”, will be understood to imply the inclusion of a stated element or group of elements but not the exclusion of any other element or group of elements. The word “include,” or variations such as “includes” or “including,” will be understood to imply the inclusion of a stated element or group of elements but not the exclusion of any other element or group of elements. Claims that do not contain the terms “means for” and “step for” are not intended to be construed under 35 U.S.C. §112, paragraph 6.