Efficient table access for reversible variable length code...

Details Efficient table access for reversible variable length code... Efficient table access for reversible variable length code...

2001-02-16

2003-04-22

Williams, Howard L. (Department: 2819)

Coded data generation or conversion

Digital code to digital code converters

To or from variable length codes

C341S065000

Reexamination Certificate

active

06552673

ABSTRACT:

BACKGROUND
The present application relates to information encoding for transmission over noisy channels and/or storage, and more particularly to error resilient coding.
The current rapid expansion of digital communication (speech, video, data) relies on increasingly economical digital signal processing. For example, video communication has general functionality as illustrated in
FIG. 8
a,
and increasingly includes a link through the air interface (
FIG. 8
b
) which can introduce noise and bit errors to the digital signal. Attempts to mitigate bit errors include the use of reversible codes as described in the following.
Commonly used video compression methods (e.g., MPEG) have block-based motion compensation to remove temporal redundancy (code only (macro)block motion vectors plus the corresponding quantized DCT residuals (texture) as in
FIG. 8
c
) and use variable length coding (VLC) to increase coding efficiency. However, variable length coding often is highly susceptible to transmission channel errors, and a decoder easily loses synchronization with the encoder when uncorrectable errors arise. Further, the predictive nature of motion compensation makes matters much worse because the uncorrectable errors in one video frame quickly propagate across the entire video sequence and rapidly degrade the decoded video quality.
The typical approach to such uncorrectable errors includes the steps of: error detection (e.g., out-of-range motion vectors, invalid VLC table entry, or invalid number of residuals in a block), resynchronization of the decoder with the encoder, and error concealment by repetition of previously transmitted correct data in place of the uncorrectable data. For example, video compressed using MPEG1-2 has a resynchronization marker (start code) at the start of each slice of macroblocks (MBs) of a frame, and an uncorrectable error results in all of the data between correctly decoded resynchronization markers being discarded. This implies degradation in quality of the video stream.
VLC tables prove to be particularly sensitive to bit errors because bit errors can make one codeword be incorrectly interpreted to be another codeword of a different length, and the error is not detected. This makes the decoder lose synchronization with the encoder. Although the error may finally be detected due to an invalid VLC table entry, usually the location in the bitstream where the error is detected is not the same as the location where the error occurred. Hence, when the decoder detects an error, it has to seek the next resynchronization marker and discard all the data between this and the previous resynchronization marker. Thus, even a single bit error can sometimes result in a loss of a significant amount of data, and this is a problem of the known coding schemes.
Enhanced error concealment properties for motion compensated compression, such as MPEG, can be achieved by using data partitioning. Consider a “video packet” to consist of the data between two consecutive resynchronization markers. In a data partitioning approach, the motion data and the texture (DCT) data within each of the video packets are separately encoded in the bitstream. Another resynchronization word (Motion Resync. Word) is imbedded between the motion data and the DCT data to signal the end of the motion data and the beginning of the DCT data. This data partitioning allows the decoder to use the motion data even if the DCT data is corrupted by undetectable errors. This provides advantages including partial recovery over uncorrectable error in a packet of compressed video data with little additional overhead. The error concealment that is made possible by the use of motion compensation by applying decoded motion vectors results in a much better decoded video quality. And this extends to video packets for intra-coded frames in that the DCT dc coefficients can be separated from the other, less important texture data (DCT ac coefficients) by a DC resynchronization word.
When using data partitioning the data within the video packet is organized to look as shown in
FIGS. 6
a-c:
FIG. 6
a
shows the fields between two resynchronization markers and
FIGS. 6
b-c
illustrate the motion data field and the texture data field in more detail by an example. In particular, the first field (“Resynch Marker”) is a resynchronization marker, the second field (“MB No.”) is the the number in the frame of the first macroblock (16×16 block of pixels) in the video packet, the third field (“QP”) is the default quantization parameter used to quantize the texture data (DCT coefficients) in the video packet, the fourth field (“Motion Data”) is the motion data, the fifth field (“Motion Resynch Word”) is the resynchronization marker between the motion data and the texture data, the sixth field (“DCT Data”) is the texture data, and the last field (“Resynch Marker”) is the ending resynchronization marker.
FIG. 6
b
shows the motion data field consisting of a COD field, an MCBPC field, and an MV field for each of the macroblocks in the packet. The COD field indicates whether the macroblock is coded or skipped (COD=0 macroblock is coded, COD=1 macroblock is skipped). The MCBPC field indicates (1) the mode of the macroblock and (2) which of the chrominance blocks in the macroblock are coded and which are skipped: the mode indicates whether the current macroblock is coded INTRA (no motion compensation), INTER (motion compensated with one 16×16 motion vector), or INTER4V (motion compensated with four 8×8 motion vectors). Of course, if COD indicates the macroblock is not coded, then the MCBPC field is not present. The MV field is the actual motion vector data; either one vector or four vectors. Again, if COD indicates that the macroblock is not coded, then the MV field is not present.
FIG. 6
c
shows the texture (DCT Data) field as consisting of a CBPY field and a DQUANT field for each of the macroblocks followed by the DCT data for each of the macroblocks. The CBPY field indicates which of the luminance blocks of the macroblock are coded and which are skipped. The DQUANT field indicates the differential increment to the default quantizer value (QP) to compute the quantization value for the macroblock. The DCT fields are run-length-encoded quantized DCT coefficient values of the macroblock.
MPEG-4 has three kinds of VLCs to encode the DCT coefficients: Table B-16 for encoding INTRA macroblocks, Table B-17 for coding INTER macroblocks, and Table B-23 which is used for coding macroblocks if reversible variable length codes (RVLC) are used. In contrast, H.263 uses only one table for encoding both the INTER and INTRA MBs: Table 13/H263. Table 13/H263 is identical to Table B-17 of MPEG-4.
Decoding normal VLCs (Table B-16/B-17 of MPEG-4 and Table 13/H263 of H.263) is done using identical techniques, thus consider the decoding of VLCs from Table 13/H263 of H.263. The length of VLC codewords in Table 13/H263 varies from 3 to 13 bits. The last bit is always a sign bit and is not used in variable length decoding, so the number of decodable bits varies up to 12. Variable length decoding is typically carried out in most of the standard decoders by using two different tables: DCT3DtabXval which contains the entries of Table 13/H263 and DCT3DtabXlen which contains the length of the corresponding codewords. Since the length of the VLC codeword is not known in advance, the fastest way to decode a VLC would be by using 2
12
(4096) entries in DCT3DtabXval. If 2
12
elements are used in DCT3DtabXval, then 12 bits from the bitstream can be read and be directly used to index into DCT3DtabXval to obtain the decoded values. The same 12 bits are indexed into DCT3DtabXlen to obtain the length of the codeword. The initial bits in the bitstream corresponding to the length of the codeword are then discarded and the process is repeated on the remaining bits plus the next bits in the bitstream up to 12 bits. Note that there are only 102 entries in Table 13/H263. Hence the DCT3DtabXval table and the DCT3DtabXlen table in sequential memory w

Affiliated with

Also associated with

Rating

Efficient table access for reversible variable length code... does not yet have a rating. At this time, there are no reviews or comments for this patent.

If you have personal experience with Efficient table access for reversible variable length code..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Efficient table access for reversible variable length code... will most certainly appreciate the feedback.

Rate now

Comments { 0 }

Profile ID: LFUS-PAI-O-3069755