WO2007027414A2

WO2007027414A2 - Macroblock neighborhood address calculation

Info

Publication number: WO2007027414A2
Application number: PCT/US2006/031480
Authority: WO
Inventors: Ankur Shah
Original assignee: Micronas Usa, Inc.
Priority date: 2005-08-31
Filing date: 2006-08-11
Publication date: 2007-03-08
Also published as: WO2007027414A3; EP1982428A2

Abstract

Techniques for addressing syntax element information of neighboring macroblocks for processing a current macroblock based on H.264 Content Based Adaptive Binary Arithmetic Coding (CABAC) are disclosed. The techniques can be used for one line of macroblocks for Frame or Field only mode, and two lines of macroblocks for MBAFF mode. The techniques can be implemented, for example, using gate-level logic state machines as part of a system-on-chip (SOC) solution for a video/audio decoder for use in high definition television broadcasting (HDTV) applications.

Description

MACROBLOCK NEIGHBORHOOD ADDRESS CALCULATION

Inventor: Ankur Shah

RELATED APPLICATIONS

[0001] This application is related to U.S. Application No. 11/181,204, filed July 13, 2005, titled "Two Pass Architecture For H.264 CABAC Decoding Process, and to U.S. Application No. (not yet known), filed August 31, 2005, titled "Multi-Stage CABAC Decoding Pipeline" <attorney docket number 22682-10709>. Each of these applications is herein incorporated in its entirety by reference.

FIELD OF THE INVENTION

[0002] The invention relates to video compression, and more particularly, to an addressing scheme for syntax element information of neighboring macroblocks used in processing a current macroblock, based on H.264 Content Based Adaptive Binary Arithmetic Coding (CABAC).

BACKGROUND OF THE INVENTION

[0003] The H.264 specification, also known as the Advanced Video Coding (AVC) standard, is a high compression digital video codec standard produced by the Joint Video Team (JVT), and is identical to ISO MPEG-4 part 10. The H.264 standard is herein incorporated by reference in its entirety.

[0004] H.264 CODECs can encode video with approximately three times fewer bits than comparable MPEG-2 encoders at the same visual quality. This significant increase in coding efficiency means that more quality video data can be sent over the available channel bandwidth. In addition, many video services can now be offered in environments where they previously were not possible. H.264 CODECs would be particularly useful, for instance, in high definition television (HDTV) applications, bandwidth limited networks (e.g., streaming mobile television), personal video recorder (PVR) and storage applications for home use, and other such video delivery applications (e.g., digital terrestrial TV, cable TV, satellite TV₅ video over xDSL, DVD, and digital and wireless cinema). . ^{■ ■ '} . • ■

[0005] In general, all standard video processing (e.g., MPEG-2 and^' H.264) encodes video as a series of pictures. For video in the interlaced format, the two fields of a frame can be encoded together as a frame picture, or encoded separately as two field pictures. Both types of encoding can be used in a single interlaced sequence. The output of the decoding process for an interlaced sequence is a series of reconstructed fields. For video in the progressive format, all encoded pictures are frame pictures. The output of the decoding process is a series of reconstructed frames.

[0006] Encoded pictures are classified into three types: I, P, and B. I-type pictures represent intra coded pictures, and are used as a prediction starting point (e.g., after error recovery or a channel change). Here, all macroblocks are coded with the prediction only from the macroblooks in the same picture. P-type pictures represent predicted pictures. Here, macroblocks can be coded with forward prediction with reference to macroblocks in previous I-type or P-type pictures, or they can, be intra coded within the same pictures. B-type pictures represent bi-directionally predicted pictures. Here, macroblocks can be coded with forward prediction (with reference to the macroblocks in previous I-type and P-type pictures), or with backward prediction (with reference to the macroblocks in, next I-type and P-type pictures), or with interpolated prediction (with reference to the macroblocks in previous and next I-type and P-type pictures), or intra coded within the same picture. In both P-type and B-type pictures, macroblocks may be skipped and not sent at all. In such cases, the decoder uses the anchor reference pictures for prediction with no error.

[0007] The advanced coding techniques of the H.264 specification operate within a similar scheme as used by previous MPEG standards. The higher coding efficiency and video quality are enabled by a number of features, including improved motion estimation and inter prediction, spatial intra prediction and transform, and context-adaptive binary arithmetic coding (CABAC) and context-adaptive variable length coding (CAVLC) algorithms. [0008] As is known, motion estimation is used to support inter picture prediction for eliminating temporal redundancies. Spatial correlation of data is used to provide intra

, picture prediction (prior to the transform). Residuals are constructed as the difference ;

. between predicted images and the source images. Discrete spatial transform and filtering is used to eliminate spatial redundancies in the residuals. H.264 also supports entropy coding of the transformed residual coefficients and of the supporting data such as motion vectors. . '

[0009] . Entropy is a measure of the average information content per source output unit, and. is typically expressed in bits/pixel. Entropy is maximized when all possible values of the source output unit are equal (e.g., an image of 8-bit pixels with an average information content of 8 bits/pixel). Coding the source output unit with fewer bits, on average, generally results in information loss. Note, however, that the entropy can be reduced so that the image can be coded with fewer than 8 bits/pixel on average without information loss. . .

[0010] The H.264 specification provides two alternative processes of entropy coding - CABAC and CAVLC. CABAC provides a highly efficient encoding scheme when it is known that certain symbols are much more likely than others. Such dominant symbols may be encoded with extremely small bit/symbol ratios. CABAC continually updates the frequency statistics of the incoming data, and adaptively adjusts the arithmetic and context model of the coding algorithm in real-time. CAVLC uses multiple variable length codeword tables to encode transform coefficients. The codeword best table is selected adaptively based on a priori statistics of already processed data. A single table is used for non-coefficient data.

[0011] The H.264 specification provides for seven profiles each targeted to particular applications, including a Baseline Profile, a Main Profile, an Extended Profile, and four High Profiles. The Baseline Profile supports progressive video, uses I and P slices, CAVLC for entropy coding, and is targeted towards real-time encoding and decoding for applications. The Main Profile supports both interlaced and progressive video with macroblock or picture level field/frame mode selection, and uses I, P, B slices, weighted prediction, as well as both CABAC and CAVLC for entropy coding. The Extended Profile supports both interlaced and progressive video, CAVLC, and uses I, P, B, SP₅ SI slices. ^{' ■} ! . ^{■ ■}

[0012] The High Profile, extends functionality of the Main Profile for effective coding. The High Profile uses adaptive 8x8 or 4x4 transform, and enables perceptual quantization matrices. The High 10 Profile is an extension of the High Profile for 10-bit component resolution. The High 4:2:2 Profile supports 4:2:2 chroma format and up to 10-bit component resolution¹ (e.g., for video production and editing). The High 4:4:4 Profile supports 4:4:4 chroma format and up to 12-bit component resolution. It also enables lossless mode of operation and direct coding of the RGB signal (e.g., for professional production and graphics).

[0013] Prior to CABAC, the arithmetic coding technique typically used in image compression is the QM-coder adopted in JPEG, JPEG2000 and JBIG standards. However, this technique uses an approximation to avoid expensive hardware multipliers, which makes the interval range updating and the probability prediction rules used in the

QM-coder implementation imprecise. This has greatly limited the efficiency of the arithmetic coding. Another limitation of the QM-coder is that it does not supply a good way for the context adaptation in the bit coding process. The context based adaptive binary arithmetic coding (i.e., CABAC) proposed by the JVT committee uses an improved version of arithmetic coder, known as an M-coder. The M-coder has not only overcome the precision issue, but also simplified the operation used to update the interval range. It replaces the use of multipliers with a modulation table, which supplies sufficient information to keep track the probability state transition and the interval change, In addition to the use of M-coder, CABAC also incorporates a bit level content adaptive scheme that fine-tunes the probability model for each bit in its decoding process based on the accumulative statistics of the same bit of the same syntax element previously decoded.

[0014] However, the JVT-proposed H.264 CABAC algorithm and its various software implementations are intrinsically serialized operations. Such a software solution is very slow in performance because there is a strong dependency between consecutive bits, due to (a) the nature of the statistical modeling in the arithmetic coding, and (b) the bit level dependency in the context modeling of the H.264 CABAC decoding process. Thus, there is no known software implementation that can meet, for instance, with the real-lime 30 frame per second for the performance requirement for the High Definition 1920x1080 ■ interlace (10801) or 1280x720 progressive (720P) formats used in the broadcast standard. In addition, an H.264 CABAC bit stream has a huge bit rate fluctuation, which makes it very difficult for any implementations to build an ASIC hardware component in a SOC system to meet the real-time performance requirement for¹ demanding applications, such as high definition video broadcasting. '

[0015] What is needed, therefore, are architectures that are H.264 CABAC enabled.

SUMMARY OF THE INVENTION

[0016] One embodiment of the present invention provides a method for addressing syntax element information of a neighboring macroblock for processing a current macroblock based on Content Based Adaptive Binary Arithmetic Coding (CABAC) decoding of 16x16 pixel macroblocks partitioned into sixteen 4x4 pixel blocks. The method includes .storing, at four corresponding dynamic locations inside a macroblock history table, syntax element information of each of four 4x4 pixel block aligning at a row boundary in a frame macroblock that WiU₁ be used for decoding future macroblocks in subsequent rows. The method further includes storing the remaining twelve 4x4 pixel blocks in twelve of sixteen corresponding static locations inside the macroblock history table. The method may also include the partitioning of each macroblocks into sixteen 4x4 pixel blocks

[0017] In response to the CABAC decoding being in a macroblock adaptive frame-field (MBAFF) mode, the method may include storing macroblock information for four 4x4 pixel blocks aligning at a column boundary into the four remaining static locations before the processing for the current macroblock begins. In one such embodiment, the macroblock history table includes 512 addresses that range sequentially from 000 to Iff hexadecimal, and the four remaining static locations are lfa, lfb, Ife, and Iff, respectively. [0018] The method may include storing syntax element information corresponding to each recently processed macroblock in the macroblock history table at, 4x4 pixel block granularity, such that each macroblock will have up to sixteen address locations in the macroblock history table. Each address location in, the macroblock history table can store, for example, up to 160 bits of syntax element information.

[0019] In another particular case where the macroblock history table includes 512 addresses that, range' sequentially from 000 to Iff hexadecimal, the four dynamic , locations are addressed at MB16xl6Index, MB16xl6Index+l, MB16xl6Index+2 and MB 16x16Index+3, respectively, where MB16xl6Index indicates current macroblock position within a frame of video data being decoded. In another particular case where the macroblock history table includes 512 addresses that range sequentially from 000 to Iff hexadecimal, the sixteen blocks have positions that are numbered from top-to-bottom and left-to-right in the sequence 0, 1, 4, 5, 2, 3, 6, 7, 8, 9, 12, 13, 10, 11, 14, 15. Here, the twelve of sixteen corresponding static locations are sequentially addressed at lfO+block position number. In one such configuration, and in response to the CABAC decoding being in a macroblock adaptive frame-field (MBAFF) mode, the method further includes storing macroblock information for four 4x4 pixel blocks aligning at block positions 5, 7, 13, and 15 into static locations addressed at lfa, lfb, lfe, and Iff, respectively, before the processing for the current macroblock begins. The method can be implemented, for example, as part of a system-on-chip (SOC), such as for a video/audio decoder for use in high definition television broadcasting (HDTV) applications.

[0020] The features and advantages described herein are not all-inclusive and, in particular, many additional features and advantages will be apparent to one of ordinary skill in the art in view of the figures and description. Moreover, it should be noted that the language used in the specification has been principally selected for readability and instructional purposes, and not to limit the scope of the inventive subject matter. BRIEF DESCRIPTION OF THE DRAWINGS

[0021] Figure 1 illustrates a mapping of a macroblock to macroblock history table ; locations, in accordance with one embodiment of the present invention. ^'

[0022] Figure 2 illustrates a left neighbor macroblock A and top neighbor macroblock B read address scheme for frame only or field only macrobloςks, in accordance with one embodiment of the present invention.

[0023J Figure 3 illustrates. a left neighbor field macroblock A address scheme for a current frame macroblock, in accordance with one embodiment of the present invention.

[0024] Figure 4 illustrates a top neighbor field macroblock B address scheme for a current frame macroblock, in accordance with one embodiment of the present invention¹. [0025] Figure 5 illustrates a left neighbor frame macroblock A address scheme for current field macroblock, in accordance with one embodiment of the present invention.

[0026] Figure 6 illustrates a top neighbor frame macroblock B address scheme for a current field macroblock, in accordance with one embodiment of the present invention.

DETAILED DESCRIPTION OF THE INVENTION

[0027] Techniques for addressing syntax element information of neighboring macroblocks for processing a current macroblock based on H.264 Content Based Adaptive Binary Arithmetic Coding (CABAC) are disclosed. The techniques can be implemented, for example, using gate-level logic state machines as part of a system-on- chip (SOC) solution for a video/audio decoder for use in high definition television broadcasting (HDTV) applications. Other video/audio decoder applications are enabled as well.

General Overview

[0028] For a H.264 CABAC context calculation of a current macroblock, syntax element information for neighboring macroblocks A (left) and B (top) is required. This implies that a CABAC decoder has to at minimum store information pertaining to one line of macroblocks for frame or field only mode, and two lines of macroblocks for MBAFF mode. [0029] To support worst case of high definition,, such as the case with 1920 x 1080 interlace and H.264 iMBAFF mode, CABAC decoders, maintain two 512xl60b sections of a macroblock history table (one section is used for frame or field only mode, and both sections are used for MBAFF mode). This macroblock history table stores 160 bits of syntax element information for up to 120 macroblocks. A method for write and read addressing into the macroblock history table, in accordance with an embodiment of the present invention, is based on the following rules: >

(a) Each 16x16 pixel macroblock is partitioned into lowermost, granularity of sixteen 4x4 pixel blocks.

(b) The syntax element information for ea'δh of the four 4x4 pixel blocks at positions 10, 11, 14, and 15 (that align at the row boundary in a frame and are used at the top neighbor macroblock B for future macroblocks in subsequent rows) is stored at dynamic locations inside the macroblock history table addressed at MB16xl6Index, MB16xl6Index+l, MB'l6xl6Index+2 and MB16xl6Index+3. MB16xl6Index = Macroblock Counter that indicates current macroblock position.

(c) The syntax element information for each of the remaining twelve 4x4 pixel blocks at . positions 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 12, and 13 (that do not align at the row boundary and can be updated after the current macroblock is processed) is stored within the last sixteen static locations inside macroblock history table addressed at 9'hifO + <position number> '

(d) As a special case for the MBAFF mode, the syntax element information for each of the four 4x4 pixel blocks at positions 5, 7, 13, and 15 (that align at the far right column macroblock boundary) is copied into locations 9'hlfa, 9'hlfb, 9'hlfe, and 9'hlff, respectively, before the processing for the current macroblock begins.

(e) After each macroblock is processed, 160 bits of syntax element information corresponding to the recently processed macroblock is stored in the macroblock history table at 4x4 block granularity.

[0030] In one particular embodiment, the method is implemented by the history table lookup stage described in the previously incorporated U.S. Application No. (not yet known), filed August 31, 2005, titled "Multi-Stage CABAC Decoding Pipeline" <attorney docket number 22682-10709>. In one such embodiment, the history table lookup stage includes a macroblock history table (e.g., ROM) and an MB_A and MB_B address calculation block implemented in gate-level logic to carryout the functionality described herein. Other configurations and embodiments will be apparent in light of this disclosure. ,_' Mapping of Macroblock to Table , , . ' '

[0031] Figure 1 illustrates a mapping of a macroblock to macroblock history table locations, in accordance with one embodiment of the present invention. As can be seen, ^',' each 16x16 pixel macroblock is partitioned into sixteen 4x4 pixel blocks, which are designated with positions 0 through 15. The syntax element information for each of these 4x4 pixel blocks is then written to corresponding locations in the macroblock history table, in accordance with the rules' previously discussed.

[0032] In one such embodiment, the write address calculation for each position is as shown in Table 1 : ■

Table 1: Macroblock History Table Write Address Calculation

Variations on this addressing scheme will be apparent in light of this disclosure. For example, the addressing scheme could descending instead of ascending (backwards from the scheme shown).

[0033] Figure 2 illustrates a left neighbor macroblock A and top neighbor macroblock B (MB B) read address scheme for frame only or field only macroblocks, in accordance with one embodiment of the present invention. [0034] As can be seen, a current macroblock is being decoded, and it has two neighbors - a left macroblock A (MB A) and a top macroblock B (MB B). CABAC context for each syntax element for a current macroblock is based on the syntax element information- of its neighboring macroblocks A and B. After processing each macroblock, the value of each syntax element is stored in a macroblock history table. In one' particular embodiment, the value of each syntax element is stored in two 512 x 160b blocks of the macroblock history table, as previously discussed. Other macroblock storage facilities and table .sizes will be apparent in light of this disclosure. ' ₍ .'

[0035] The same sixteen 4x4 block positions are used when reading from the macroblock history table. In one such embodiment, the read address calculation for each position of the left neighbor macroblock A in mode 1 is as shown in Table 2:

Table 2: Left Neighbor Macroblock A Read Address Calculation (Mode 1 : Frame Only or Field Only Macroblocks)

[0036] The read address calculation for each position of the top neighbor macroblock B in mode 1 is as shown in Table 3:

4x4 Block Macroblock History Position Table Read Address

Table 3: Top Neighbor Macroblock B Read Address Calculation (Mode 1 : Frame Only or Field Only.Macroblocks)

[0037] Mode 2 involves a macroblock-adaptive frame-field (MBAFF) pair., , A number of cases are possible when decoding a frame-field MBAFF pair. A first case involves a current frame macroblock, and a left neighbor field macroblock A. A second related case involves a current frame macroblock, and a top neighbor field macroblock B. A third case involves a current field macroblock, and a left neighbor frame macroblock A. A fourth related case involves a current field macroblock, and. a top neighbor frame macroblock B.

[0038] Figure 3 illustrates a left neighbor field macroblock A address scheme for a current frame macroblock, in accordance with one embodiment of the present invention. The mode 2 read address calculation for each position of the left neighbor field macroblock A for the current top frame macroblock is as shown in Table 4.

Table 4: Left Neighbor MB A Read Address Calculation for Current Top Frame MB (Mode 2: Current Frame MB, Top Neighbor Field MB A)

[0039] The mode 2 read address calculation for each position of the left neighbor field macroblock A for , the current bottom frame macroblock is as shown in Table 5. Note here that only the address for positions 0, 2, 8 and 10 change from Table 4 to Table 5. The addresses for the other positions remain the same for this case of mode 2. This is why these position are bolded.

Table 5: Left Neighbor MB A Read Address Calculation for Current Bottom Frame MB (Mode 2: Current Frame MB, Top Neighbor Field MB A)

[0040] Figure 4 illustrates a top neighbor field macro'block B address scheme for a current frame macroblock, in accordance with one embodiment of the present invention. The mode 2 read address calculation for each position of the top neighbor field macroblock B for the current top and bottom frame macroblocks is as shown in Table 6.

Table 6: Top Neighbor MB B Address Calculation for Current Top and Bot Frame MB (Mode 2: Current Frame MB₅ Top Neighbor Field MB B)

[0041] Figure 5 illustrates a left neighbor frame macroblock A address scheme for current field macroblock, in accordance with one embodiment of the present invention. The mode 2 read address calculation for each position of the left neighbor frame macroblock A for the current top field macroblock is as shown in Table 7.

Table 7: Left Neighbor MB A Address Calculation for Current Top MB (Mode 2: Current Field MB, Left Neighbor Frame MB A)

[0042] The mode 2 read address calculation for each position of the left neighbor frame macroblock A for the current top field macroblock is as shown in Table 8. Note here that only the address for positions 0, 2, 8 and 10 change from Table 7 to Table 8. The addresses for the other positions remain the same for this case of mode 2. This is why these position are bolded.

Table 8: Left¹ Neighbor MB A Address. Calculation for Current Bottom MB ^• (Mode 2: Current Field MB₅ Left Neighbor Frame MB A)

[0043] Figure 6 illustrates a top neighbor frame macroblock B address scheme for a current field macroblock, in accordance with one embodiment of the present invention. The mode 2 read address calculation for each position of the top neighbor frame macroblock B for the current top and bottom field macroblock is as shown in Table 9.

Table 9: Top Neighbor MB B Address Calculation for Current Top and Bottom MB (Mode 2: Current Field MB, Top Neighbor Frame MB B)

[0044] The foregoing description of the embodiments of the invention has been presented for the purposes of illustration and description. It is not intended to be exhaustive or to limit the invention to the precise form disclosed. Many modifications and variations are possible in light of this disclosure. For example, the read/write addressing scheme can be implemented in either an ascending or descending order within the macroblock address history table. Likewise, the granularity of the macroblock partitioning into blocks can be adjusted to suit another set of static and dynamic addresses, in accordance with an embodiment of the present invention. It is intended that the scope of the invention be limited not by this detailed description, but rather by the

, claims appended hereto. ^■

Claims

CLAIMSWhat is claimed is;

1. A method for addressing syntax element ' information of a neighboring macroblock for processing a current macroblock based on Content Based Adaptive Binary Arithmetic Coding (CABAC) decoding, the method comprising: partitioning each 16x16 pixel macroblock into sixteen 4x4 pixel blocks; storing, at four corresponding dynamic locations inside a macroblock history table, syntax element information of each of four 4x4 pixel block aligning at a row boundary in a frame macroblock that will be used for decoding ■future macroblocks in subsequent rows; and storing the remaining twelve 4x4 pixel blocks in twelve of sixteen corresponding i static locations inside the macroblock history table.

2. The method of claim 1 wherein response to the CABAC decoding being in a macroblock adaptive frame-field (MBAFF) mode, the method further comprises: storing macroblock information for four 4x4 pixel blocks aligning at a column boundary iηto the four remaining static locations before the processing for the current macroblock begins.

3. The method of claim 2 wherein the macroblock history table includes 512 addresses that range sequentially from 000 to Iff hexadecimal, and the four remaining static locations are lfa, lfb, lfe, and Iff, respectively.

4. The method of claim 1 further comprising: storing syntax element information corresponding to each recently processed macroblock in the macroblock history table at 4x4 pixel block granularity, such that each macroblock will have up to sixteen address locations in the macroblock history table.

5. The method of claim 1 wherein each address location in the macroblock history table stores up to 160 bits of syntax element information.

6. ' , The method of claim 1 wherein the macrόblock history table includes 512 addresses that range sequentially from 000 to Iff hexadecimal, and the four, dynamic locations are addressed at MB16xl6Index, MB16xl6Ihdex+l, MB16xl6Index+2 and, MB16xl6Index+3, respectively, where MB16xl6Index indicates current macrόblock position within a frame of video data being decoded. < • , ^■

7. The method of claim 1 wherein the macroblock history table includes 512 addresses that range sequentially from 000 to Iff hexadecimal, and the sixteen blocks have, positions that are numbered from top-to-bottom and left-to-right in the sequence 0, 1, 4, 5, 2', 3, 6, 7, 8, 9, 12, 13, 10, 11, 14,' 15, and the twelve of sixteen corresponding static locations are sequentially addressed at lfO+block position number. ,

8. , The method of claim 7 wherein response to the CABAC decoding being in a macroblock adaptive frame-field (MBAFF) mode, the method further comprises: storing macroblock information for four 4x4 pixel blocks aligning at block positions 5, 7, 13, and 15 into static locations addressed at lfa, lfb, lfe, and Iff, respectively, before the processing for the current macroblock begins.

9. The method of claim 1 implemented as part of a system-on-chip (SOC).

10. A method for addressing syntax element information of a neighboring macroblock for processing a current macroblock based on Content Based Adaptive Binary Arithmetic Coding (CABAC) decoding, the method comprising: partitioning each 16x16 pixel macroblock into sixteen 4x4 pixel blocks, wherein the sixteen blocks have positions that are numbered from top-to-bottom and left-to-right in the sequence 0, 1, 4, 5, 2, 3, 6, 7, 8, 9, 12, 13, 10, 11, 14, 15; storing, at four corresponding dynamic locations inside a macroblock history table that includes 512 addresses ranging sequentially from 000 to Iff hexadecimal, syntax element information of each of four 4x4 pixel block aligning at a row boundary in a frame macroblock that will be ,used for decoding future macroblocks in subsequent rows; storing the remaining twelve 4x4 pixel blocks in twelve of sixteen corresponding . _t macroblock history table static locations addressed at lfO+block position number; and , storing syntax element information corresponding to each recently processed macroblock in the macroblock history table at 4x4 pixel block granularity, such that each macroblock will have μp to sixteen address locations in the macroblock history table. ' *

11. The method of claim 10 wherein response to the CABAC decoding being in a macroblock adaptive fϊame-field (MBAFF) mode, the method further comprises: storing macroblock, information for four 4x4 pixel blocks aligning at a column boundary into, the four remaining static locations before the processing for the current macroblock begins. .

12. The method of claim 11 wherein ,the four remaining static locations are lfa, lfb, lfe, and Iff, respectively. ^■

13. The method of claim 10 wherein each address location in the macroblock history table stores up to 160 bits of syntax element information.

14. The method of claim 10 wherein the four dynamic locations are addressed at MB16xl6Index, MB16xl6Index+l, MB16xl6Index+2 and MB16xl6Index+3, respectively, where MB16xl6Index indicates current macroblock position within a frame of video data being decoded.

15. The method of claim 10 wherein response to the CABAC decoding being in a macroblock adaptive frame-field (MBAFF) mode, the method further comprises: storing macroblock information for four 4x4 pixel blocks aligning at block positions 5, 7, 13, and 15 into locations addressed at lfa, lfb, lfe, and Iff, respectively, before the processing for the current macroblock begins.

16.' , The method of claim 10 implemented as part of a system-on-chip (SOC).

I ._. 17. A method for addressing syntax element information of a neighboring ' macroblock for processing a current macroblock based on Content Based Adaptive ¹ ^■ Binary Arithmetic Coding (CABAC) decoding of 16x16 pixel macroblocks partitioned into sixteen 4x4 pixel blocks, the method comprising:

, storing, at four corresponding dynamic locations inside a macroblock history table, syntax element information of each of four 4x4 pixel block aligning at a row boundary in a frame macroblock that will be used for decoding future macroblocks in subsequent rows; and

' storing the remaining twelve 4x4 pixel blocks in twelve of sixteen corresponding static locations inside the macroblock history table.

18. The method of claim 17 wherein response /to the CABAC decoding being , in a macroblock adaptive frame-field (MBAFF) mode, the method further comprises:

. storing macroblock information for four 4x4 pixel blocks aligning at a column boundary into the four remaining static locations before the processing for the current macroblock begins.

19. The method of claim 18 wherein the macroblock history table includes 512 addresses that range sequentially from 000 to Iff hexadecimal, and the four remaining static locations are lfa, lfb, lfe, and Iff, respectively.

20. The method of claim 17 further comprising: storing syntax element information corresponding to each recently processed macroblock in the macroblock history table at 4x4 pixel block granularity, such that each macroblock will have up to sixteen address locations in the macroblock history table.

21. The method of claim 17 wherein the macroblock history table includes 512 addresses that range sequentially from 000 to Iff hexadecimal, and the four dynamic locations are addressed at MB16xl6Index, MB16xl6Index+l, MB16xl6Index+2 and MB16xl6Index+3,_' respectively, where MB16xl6Index indicates current macroblock position within a frame of video data being decoded. . _, .

22. The method of claim 47 wherein the macroblock history table includes 512 addresses that range sequentially from 000 to Iff hexadecimal, and the sixteen blocks have positions th,at are numbered from toρ-tθrbottom arid left-to-right in the sequence 0, 1, 4, 5, 2, 3, 6,' 7, 8, 9, 12, 13, 10, 11, 14, 15, and the twelve of sixteen corresponding static locations are sequentially addressed at lfO+block position number.

23. The method of claim 22 wherein response to the CABAC decoding being in a macroblock adaptive frame-field (MBAFF) mode, the method further comprises: storing macroblock information for four 4x4 pixel blocks aligning at block positions 5,.7, 13, and 15 into static locations addressed at lfa, lfb, lfe, and Iff, respectively, before the processing for the current macroblock begins. _. , '

24. The method of claim 17 implemented as part of a system-on-chip (SOC).