Arbitrary slice ordering

• Impact of ASO on AVC decoders complexity

An example of how macroblocks can be associated to different slices is shown in Figure 1. When ASO is supported, the four slices of this example can be received by the decoder in a random order. Figure 2 shown the following receiving order: slice #4, slice #3, slice #1, and slice #2. The same figure presents the AVC decoder blocks required to support ASO decoding.

Figure 1: An example of macroblock assignment to four slices. Each slice is represented by a different texture.

Figure 2: The AVC decoder blocks need to support ASO decoding.

For each slice, the slice length and the macroblock address (i.e. index with respect to the raster scan order) of the first macroblock (MB) of the slice are extracted by the slice parser (Figure 2). This information, together with the slice itself, is stored in memory (shown as DRAM). In addition, a list of pointers (Figure 2, a pointer for each slice, and each pointing to the memory location where a slice is stored), should be generated. The list of pointers, together with the address of the first macroblock of the slice, will be used to navigate through the out of order slices. The slice length will be used to transfer the slice data from the DRAM to the decoder's internal memory.

Faced with the necessity to decode out of order slices, a decoder may:

• 1) wait for all the slices of each picture to arrive before start decoding and de-blocking the picture.
• 2) decode the slices in the order in which they come to the decoder.

The first method increases latency, but allows performing decoding and de-blocking in parallel. However, managing a large number of pointers (in the worst case, one pointer for each MB) and increasing the intelligence of the DRAM access unit increase the decoder complexity.

The second method hurts significantly the decoder performance. In addition, by performing the de-blocking in a second pass, the DRAM to processor's memory bandwidth is increased.

Decoding slices in the order they are received can result in additional memory consumption or impose higher throughput requirements on the decoder and local memory to run at higher clock speed. Consider an application in which the display operation reads the pictures to be displayed right from the section of memory where the decoder stored the pictures.

• Impact of ASO and FMO on AVC decoders complexity

An example of how slices can be associated to different slice group is shown in Figure 3. When ASO and FMO are supported, the four slices of this example can be received by the decoder in a random order. Figure 2 shown the following order: slice #4, slice #2, slice #1, and slice #3. The same figure presents the AVC decoder blocks required to support ASO and FMO decoding.

Figure 3: An example of macroblock assignment to four slices and to two ''Slice'' Group (SG in the figure). Each slice is represented by a different texture, and each Slice Group is represented a different color.

Figure 4: The AVC decoder blocks need to support ASO and FMO decoding.

In addition to the slice length and the macroblock address of the 1st macroblock (MB) of the slice, the slice parser (Figure 4) need to extract the Slice Group (SG) of each slice. These informations, together with the slice itself, are stored in DRAM. As in the ASO case, the list of pointers (Figure 4) should be generated.

The list of pointers, together with the address of the 1st MB of the slice, the SG, and the mb_allocation_map (stored in the processor's local memory), will be used to navigate through the slices. The slice length will be used to transfer the slice data from the DRAM to the processor local memory.

Similarly to the ASO case, in the combined ASO and FMO case the decoder may:

• 1) wait for all the slices of each picture to arrive before start decoding and de-blocking the picture.
• 2) decode the slices in the order in which they come to the decoder.

The first approach is still the preferred one. Because of FMO, decoding macroblocks in raster scan order may require to switch between different slices and/or slice groups. To speed up the DRAM access, one buffer for each Slice Group must be used (Figure 4). This additional intelligence of the DRAM access unit further increase the decoder complexity. Moreover, switching between different slices and/or slice groups requires swapping the Entropy Decoder (ED) status information. In the worst case, swapping occurs after decoding each macroblock. If the entire Entropy Decoder status information is too large to be stored in the processor local memory, each ED status need to be loaded from and stored into DRAM, thus further increasing the DRAM to processor's memory bandwidth (Figure 4).