1. Field of the Invention
The present invention relates to digital video coding technology, and more particularly to a system and method for carrying out video coding through DCT (Discrete Cosine Transform), motion compensation and motion estimation.
2. Description of the Related Art
In a conventional video coding system, the circuit configuration and control method of a variable-length encoder are becoming increasingly complex with the development of a video compression/decompression standard. For example, when video is coded using the MPEG-4 (Moving Picture Experts Group 4) video coding standard, a data partitioning mode can be used to enhance error resilience. In this case, a texture of a macroblock and two headers in a single video packet must be sent on a type-by-type basis. In a structure of the variable-length encoder for separately sending the headers and the texture in a macroblock unit, complex control must be carried out so that a user configures a video packet, such that there is a problem in that the load of a CPU (Central Processing Unit) controlling the video coding system increases.
FIG. 1 is a block diagram illustrating an example of a conventional encoder based on MPEG-4. Referring to FIG. 1, an encoder 100 comprises an ME (Motion Estimation) unit 101; an MC (Motion Compensation) unit; a DCT/Q (Discrete Cosine Transform/Quantization) unit 103a; an ADP (AC/DC Prediction) unit 104; a VLC (Variable Length Coding) unit 105; and an IQ/IDCT (Inverse Q/Inverse DCT) unit 106.
The ME unit 101 carries out a task for estimating a motion change of a current frame from a previous frame. A result of the task is represented by a motion vector. The motion vector indicates the quantity and direction of movement of a related macroblock or block of the current frame from the previous frame. When this motion estimation is used, temporal iteration is removed and hence coding quantity can be reduced. The macroblock consists of 16×16 pixels, and is configured by 4 luminance blocks and 2 chrominance blocks. Thus, the macroblock contains a total of 6 blocks and each block consists of 8×8 pixels.
The MC unit is divided into MC (−) (MC minus) 102a and MC (+) (MC plus) 107. The MC (−) 102a carries out a task for subtracting a motion estimation result of the previous frame from the current frame, thus producing frame data in which temporal iteration is removed. The MC (+) 107 carries out a task for adding the previous frame used in the MC (−) 102a to a result produced by the IQ/IDCT part 106 to be described below, thus obtaining a video frame to be finally viewed through a decoder. This video frame is utilized as the previous frame when the next frame is coded.
The DCT/Q unit 103a transforms video data of a spatial domain into video data of a frequency domain, and quantizes a result of the transformation to limit the video data of the frequency domain to a discrete set of values.
The ADP unit 104 produces a difference value between an AC/DC coefficient of a current block and an AC/DC coefficient of a surrounding block. This is aimed to reduce coding quantity using spatial continuity.
The VLC unit 105 performs variable length coding on coefficients in which ADP has been completed, thereby generating a coded bitstream. At this point, the bitstream is configured in the form of a video packet containing data of the predetermined number of macroblocks.
The IQ/IDCT unit 106 performs inverse quantization on coefficients in which DCT/Q has been completed and transforms a result of the inverse quantization into data of the spatial domain. Video after the IQ/IDCT is different from video after the MC (−) in that data of the video after the IQ/IDCT may be slightly lost by quantization and inverse quantization of the DCT/Q unit 103a and the IQ/IDCT unit 106. However, the video data based on the quantization and inverse quantization is obtained to produce video data appropriate to a decoder.
FIG. 2 is a block diagram illustrating a conventional image coding system. The conventional video coding system comprises an encoder 100, memories 204 and 205, a CPU (Central Processing Unit) 201, a main memory 202 and a data bus 203.
An encoder 100 is divided into a motion estimation section and a texture coding section. The motion estimation section is configured by an ME (Motion Estimation) unit 101 and the texture coding section is configured by an MC (Motion Compensation) unit 102, a DCT/IDCT (Discrete Cosine Transform/Inverse Discrete Cosine Transform) unit 103, an ADP (AC/DC Prediction) unit 104 and a VLC (Variable Length Coding) unit 105. The two sections can operate independently of each other. However, texture coding requires a motion vector produced after ME is performed.
ME in the ME unit 101 operates in a macroblock unit. During the ME, the texture coding section including the units 102 to 105 iterate an operation based on a unit of a block 6 times.
The memories 204 and 205 store data necessary for texture coding, and the CPU 201 and the main memory 202 control operations associated with blocks.
The data bus 203 is provided so that the encoder 100 can exchange data with an external memory.
FIG. 3 shows a sequence of a method for coding a frame consisting of N macroblocks using the encoder based on a pipeline structure.
First, ME (Motion Estimation) for Macroblock 0 is performed. At this point, because a motion vector of Macroblock 0 is not present, texture coding of Macroblock 0 cannot be performed.
Subsequently, while the ME for Macroblock 1 is performed, the motion vector of Macroblock 0 appears and simultaneously the texture coding for Macroblock 0 can be performed. In this manner, when the coding is performed, the ME for the last macroblock is not performed and only texture coding for the last macroblock is performed.
FIG. 4 is a block diagram illustrating the conventional VLC (Variable Length Coding) unit.
A header indicating the characteristics of the macroblock and a texture in which video data is included configures a coded macroblock.
A header coding control part (header_ctrl) 306 is responsible for controlling header coding.
A header ROM (Read Only Memory) table (mb_rom) 307 includes various tables necessary for the header coding.
A header memory (hmem) 305 stores a result of the header coding.
A texture coding control part (texture_ctrl) 302 is responsible for controlling texture coding.
A texture ROM table (ac_rom) 303 includes various tables necessary for the texture coding.
A texture memory (tmem) 301 stores a result of the texture coding.
A VLC register (vlc_reg) 304 receives various setup items necessary for the header and texture coding from the CPU 201 and provides the received setup items to the texture coding control part (texture_ctrl) 302 and the header coding control part (header_ctrl) 306. Furthermore, the VLC register (vlc_reg) 304 receives information indicating how many bits have been generated as a result of the coding from the texture coding control part (texture_ctrl) 302 and the header coding control part (header_ctrl) 306, and provides the received information to the CPU 201.
FIG. 5 is a flowchart illustrating a VP (Video Packet) coding process when data is partitioned. Here, the VP is a unit of data for packing one or more macroblocks. A fixed-length code (resynchronization marker) of a bitstream is arranged in a header of the VP and part of frame header information is repeated subsequent to the fixed-length code, such that error resilience is enhanced. A data partitioning mode is an operating mode for positioning important header information at a leading portion of the VP. Headers are classified into Header 1 and Header 2 according to importance. A marker consisting of a specific bitstream is inserted between Header 1 and Header 2.
Referring to FIG. 5, a resynchronization marker and a VP header are inserted (S100).
Subsequently, macroblock coding is carried out (S110). When the coding is completed, bitstreams of Header 1 and Header 2 are stored in the header memory (hmem) 305 and a bitstream of a texture is stored in the texture memory (tmem) 301.
Subsequently, the main memory 202 stores the bitstreams of the Header 1, Header 2 and texture in separate spaces, respectively (S112 to S116). After all macroblocks contained in the VP are coded, independent spaces are required so that the Header 1, Header 2 and texture can be merged with other Headers 1, other Headers 2 and other textures, respectively.
Subsequently, a determination is made as to whether or not the VP has been completed (S118). A total length value of Headers 1, Headers 2 and textures is calculated after the first macroblock of the VP. When the calculated value is larger than a predetermined target value, it is determined (S120) that the VP has been completed.
If the VP has been completed, step S122 is performed. Otherwise, the above step S110 is performed. At the above step S122, a process for packing the Headers 1, Headers 2 and texture produced from the macroblocks corresponding to the current VP is performed.
At last, a VP stream is fetched at step S124.
As described above, a user must merge header and texture bitstreams produced as a result of macroblock coding in the prior art, and hence the load of a CPU increases. In particular, when data has been partitioned, the Headers 1, Headers 2 and textures of all macroblocks in the VP are separately stored. Then, when the VP has been completed, the user must perform a packing task for merging the Headers 1, Headers 2 and textures. The packing task requires a large number of bit shifts and memory inputs and outputs, resulting in an increased load of the CPU. This problem cannot be fundamentally addressed by the conventional coding system even though a coding method is changed.
USPTO Backgrounds
USPTO Backgrounds