Abstract:
A method, system and computer program for decompressing video data, storing the compressed video data in such a way that random access is possible and the data can be mapped efficiently into existing memory systems and interface protocols. The compression is accomplished via lossless compression using an algorithm optimized for video data. Due to the compressed format, data transmission consumes less bandwidth than using uncompressed data and prevents degradation in the decoded video.

Description:
RELATED APPLICATIONS 
       [0001]    The present application claims priority to U.S. Provisional Application No. 61/908,853, filed Nov. 25, 2013, assigned to Assignee hereof, the specification of which is incorporated herein by reference. 
     
    
     TECHNICAL FIELD 
       [0002]    The disclosed methods, computer programs, and systems relate to communication systems, and more particularly to optimizing bandwidth in accessing external memory components when used in a video processing and display system. 
       BACKGROUND 
       [0003]    A common implementation of a system is to have specialized components which are built in a cost effective manner that are combined together to form a system that performs a set of functions. In most video processing systems such as a set-top box, there is a main processing unit, such as system on chip, and external memory devices, in addition to various interface and support devices. The external memory is often used to store temporary data required by the system in order to achieve the function. In the case of a video processing system, external memory is often used to hold video images before they are displayed. 
         [0004]    A common problem with the implementation of the system is that the interface between the main processing unit, the system on chip, and the external memory has a limited bandwidth. In general, the smaller the number of pins an interface requires, the cheaper it is to manufacture. Technology and speed also play a large part in the performance, but often these are limited by the memory technologies available in volume quantities, such as dynamic random-access memory devices. 
       SUMMARY 
       [0005]    The following presents a simplified summary of one or more embodiments in order to provide a basic understanding of some aspects of such embodiments. This summary is not an extensive overview of the one or more embodiments, and is not intended to identify key or critical elements of the embodiments or delineate the scope of such embodiments. Its sole purpose is to present some concepts of the described embodiments in a simplified form as a prelude to the more detailed description that is presented later. 
         [0006]    The claimed embodiments are targeted to improve the amount of effective bandwidth that can be realized through the system on chip to memory interface by compressing the data so that it takes less bandwidth to transmit the same amount of information. 
         [0007]    Typical strategies to solve the problem of limited bandwidth are to increase the width of the interface, allowing for more data to be transferred in parallel, or to run the interface at a higher effective speed. The number of pins is typically increased in discrete blocks of pins to allow for easier management and addressing of the data transferred between the memory device and the system on chip control system. Each additional pin will add to the system cost of the implementation. 
         [0008]    The speed of operation of the interface is most often dictated by the design of the memory interface device and the protocol implemented on the interface. The state of the art technology will generally set the speed of the interfaces to a maximum value for a certain technology and protocol. To make a device cost effective to manufacture and produce, there is a limited number of supported protocols. Standardizing the protocol allows for many systems to use the same memory device for many different functions, increasing the volume of manufacturing and reducing the cost for the memory devices. 
         [0009]    Increased performance can be achieved with specialized protocols and memory devices, but these are generally higher in overall costs due to lower overall volume and less manufacturing scaling. 
         [0010]    Another common solution used to save bandwidth is to compress the data to be stored. Raw data is compressed into a smaller data set, transferred across the interface, stored in the memory devices and later retrieved for use. Because the data set is smaller due to compression, less bandwidth is needed on the interface to transfer the information. 
         [0011]    Compression technologies fall into two categories, lossless and lossy compression. Lossy compression will result in a loss of information after decompression, while the lossless will not lose any information when the data is compressed and decompressed. The tradeoff between the two modes is that lossy compression can generally be controlled to give a predictable amount of compression, and therefore, can be applied easily into a system that allocates a certain bandwidth and memory storage for the compressed data. Lossy data compression is used extensively in video display and processing systems to reduce the amount of system bandwidth needed to transmit video images. 
         [0012]    However, within a video processing system itself, a lossless memory system is generally needed to correctly perform the video processing functions. Lossless memory storage is needed in many video processing systems because the system will rely on exact data from previous and future images to generate a current picture. One major problem with using lossless data compression within a video processing system is that it is not possible to predict the amount of compression that can be realized. The amount of compression realized will depend on the data itself. This severely complicates the process of making random access into the compressed data to retrieve a portion of the data to be used for processing. To make a random access often requires the decompression of a larger amount of data, increasing the local storage requirements greatly and increasing the latency to a level where the data cannot be retrieved in time to be displayed. 
         [0013]    Video systems generally require access to small two dimensional blocks of video data that is stored in external memory. Memory systems are organized in two dimensions as well, and this maps well to storing and accessing uncompressed video data. The dimensions and access patterns can be optimized to allow for efficient access using the common protocols. However, when variable sized compressed data is stored, the access alignment to this data cannot be made efficiently and the effective bandwidth on the interface is severely reduced. 
         [0014]    The claimed embodiments address these problems by compressing the data with an algorithm optimized for video data, and storing the compressed data in such a way that random access is possible and data can be mapped efficiently onto the existing memory system and interface protocols. Since the data is stored in a compressed format, it will consume less bandwidth to transfer the same amount of data, allowing for more data to be transmitted in the same amount of time as before, increasing the overall bandwidth. This is a novel approach, as it allows for compression with more deterministic access and addressability. 
     
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         [0015]    The disclosed method and apparatus, in accordance with one or more various embodiments, is described with reference to the following figures. The drawings are provided for purposes of illustration only and merely depict examples of some embodiments of the disclosed method and apparatus. These drawings are provided to facilitate the reader&#39;s understanding of the disclosed method and apparatus. They should not be considered to limit the breadth, scope, or applicability of the claimed invention. It should be noted that for clarity and ease of illustration these drawings are not necessarily made to scale. 
           [0016]      FIG. 1  illustrates three (3) cases of uncompressed chunks in different percentages. 
           [0017]      FIG. 2  illustrates how chunks are stored sequentially in memory. 
           [0018]      FIG. 3  shows an example of two consecutive chroma chunks. 
           [0019]      FIG. 4  shows an example of a 10 bit video requires a new video buffer format structure. 
           [0020]      FIG. 5  shows a 4×4 block subdivided into four 2×2 sub-blocks. 
           [0021]      FIG. 6  shows a unidirectional slope embodiment example. 
           [0022]      FIG. 7  shows a corner impulse embodiment example. 
           [0023]      FIG. 8  shows a diagonal embodiment example. 
           [0024]      FIG. 8  shows an example of the predicted surface after the second order stage is an arbitrary two-dimensional slope. 
           [0025]      FIG. 10  shows the re-calculation the 3rd order stage of the four 2×2 sub-blocks. 
           [0026]      FIG. 11  shows a class map for a “ridge”. 
           [0027]      FIG. 12  shows a class map for a “centre impulse”. 
           [0028]      FIG. 13  shows a class map for a “checker board”. 
           [0029]      FIG. 14  shows a class map for a “peak”. 
           [0030]      FIG. 15  shows a class map for a “saddle”. 
           [0031]      FIG. 16  shows an example of a combination of a 1st order and 3rd order surface “slope plus ridge”. 
           [0032]      FIG. 17  shows an example of an arbitrary surface possible with three stages. 
           [0033]      FIG. 18  shows the basic system architecture of the preferred embodiment. 
           [0034]      FIG. 19  is a block diagram that shows the dataflow inside the Decompressor Data Engine (DDE). 
           [0035]      FIG. 20  is a flow chart that shows the control flow in the decompressor. 
           [0036]      FIG. 21  is a block diagram showing the dataflow inside the Compressor Data Engine (CDE). 
       
    
    
       [0037]    The figures are not intended to be exhaustive or to limit the claimed invention to the precise form disclosed. It should be understood that the disclosed method and apparatus can be practiced with modification and alteration, and that the invention should be limited only by the claims and the equivalents thereof. 
       DETAILED DESCRIPTION 
       [0038]    The embodiments claimed herein use the inherently limited frequency spectrum in video data to losslessly compress the data in order to reduce the memory bandwidth. By mapping predefined surfaces to the image, and then encoding the differences the compression, can approach 50%. However, for difficult images, compression may not be achieved, and therefore the embodiments discussed in this disclosure are useful in applications where bandwidth reduction is advantageous, as opposed to strictly necessary. 
         [0039]    The savings in the bandwidth required is reduced to a range between 60% and 70% of normal. This is particularly important to achieve decode and display of 4K ultra high definition television at an acceptable cost. 
         [0040]    This disclosure assumes lossless compression is required so that there is no degradation in the decoded video due to error propagation through inter-coded or intra-coded pictures. Lossless compression also retains the ability for automated decoded picture verification such as picture cyclic redundancy check calculations. 
         [0041]    The purpose of the claimed embodiments is to reduce the bandwidth of the memory accesses required to decode and display the video and not to reduce the storage requirements. This results in reducing the cost of the system by avoiding a wider bus between the system on chip and the double data rate memory devices or dynamic random-access memory devices. A wider bus requires more input/output pins on the system on chip, a larger system on chip package, more physical memory devices, and more board space and therefore more cost. Moreover it is assumed that there is a cost penalty associated with increasing the number of double data rate memory devices but proportionally reducing each devices capacity. This is because the cost of devices does not scale linearly with their capacity. 
         [0042]    The embodiments disclosed do not reduce the storage requirements. In fact, it slightly increases the storage in order to store some sideband information about each block 
         [0043]    A severe problem with other types of memory compression is that variable compression rates cause the addressing scheme to become very complicated. This can make random access into the decoded video next to impossible, which may not be a problem for just storage and display where all the pixels are addressed in a simple linear sequence, but will make such schemes unusable to a video decoder where random access is required for motion compensation. 
         [0044]    In the claimed embodiments, the compressed memory chunks are collocated with their uncompressed equivalents. This makes the addressing scheme virtually unchanged and therefore simple to implement. If the chunk is successfully compressed then it replaces the first half of the uncompressed chunk and the second half is unused. If the chunk cannot be compressed, then it is simply stored, uncompressed. 
         [0045]    A refinement to the embodiments adds a second level of compression where chunks that can be compressed to 75% are also handled. If a chunk does not fit within 50%, then it is tested to see if it fits within 75%. A further possible refinement is to allow yet another level of compression, e.g. 87.5%, although the efficiency gains are diminishing. 
         [0046]      FIG. 1  shows the three (3) cases of uncompressed chunks  10 , chunks compressed to 75%  12  and chunks compressed to 50%  14  (compression to 87.5% is not shown). In all cases, a read operation will fetch the first half of the chunk (denoted as RAW A) and only fetch RAW B if it is present. Each chunk in this example is 128×1 bytes, as indicated in  FIG. 1 . 
         [0047]    Memory addressing is not significantly impacted because compressed chunks are stored in the first half of where the uncompressed chunks would be. A “chunk” is defined as a unit of compression. 
         [0048]    Chunks will be addressed in fixed units that represent two dimensional arrays of pixels on the display, for example 32×4 or 64×4 arrays of pixels. The algorithm requires that the dimensions of the arrays are multiples of 4 pixels. Increasing the width improves both the memory efficiency and the compression efficiency, but excessive width will reduce the caching efficiency for random access (since it becomes more likely that time is wasted fetching unwanted pixels). Increasing the height would have all the same effects as increasing the width, but with an additional penalty of significantly increasing the cost of the line buffers required for scanline access for display. Therefore, the optimal configuration is a wide rectangle and for the rest of this disclosure, the size will be assumed to be 32×4, although this disclosure is intended to cover other sizes. 
         [0049]    Chunks are stored sequentially in memory starting from the chunk representing the top left pixels of the display and then progressing left to right and then down. This is shown in  FIG. 2  where n is the number of horizontal chunks needed to store the picture and chunk  0   20  is the 32×4 array of pixels at (0, 0) to (3, 31), chunk  1   22  is the 32×4 array of pixels at (0, 32) to (3, 63), chunk n  24  is the 32×4 array of pixels at (4, 0) to (7, 31), etc. Each pixel component is either, 8, 10 or 12 bits. 
         [0050]    For luma data a 32×4 array will represent a horizontal series of eight 4×4 blocks. For interleaved chroma data a 32×4 array will represent two independent horizontal series each of four 4×4 blocks. In this embodiment it is assumed that a typical subsampled chroma is used in the Moving Picture Experts Group (MPEG) video compression. This is where each chroma component, Cr  28  and Cb  26 , is subsampled by a factor of two in both the x and y dimensions. It is also assumed that the two chroma components are interleaved so that a horizontal line of luma (Y) data occupies the same storage space as a horizontal line of interleaved chroma (CbCr) data, although there is half the number of chroma lines compared to luma lines. However, the claimed embodiments apply equally to other chroma formats, in particular the non-subsampled case where there are simply three component planes, one for each of Y, Cb, and Cr, the embodiment simply applies identically to each plane with no special handling for chroma. An example of two consecutive chroma chunks is in  FIG. 3 , where Cb  26  represents the blue-difference color component and Cr  28  represents the red-difference color component. 
         [0051]    The algorithm does not inherently handle interlaced video which requires a modified algorithm or a modified storage scheme (separate field buffers). If interlaced video is transmitted without the use of interlaced tools, i.e. as a sequence of field pictures, and decoded into field picture buffers, then no change to the algorithm or storage scheme is required. Obviously, the display pipeline must be able to handle interlaced video from separate field buffers. 
         [0052]    A 10 bit video requires a new video buffer format regardless, but for efficiency, the proposed new structure is similar to the following example, as depicted in  FIG. 4 . The first row of bytes  16  holds the low order 2-bits/pixel packed together, the remaining 4 rows  18  hold the same 32×4 (or 64×4) 8-bit pixels as before. Each byte in first row  16  hold the low order 2 bits of the 4 pixels immediately below it as shown below: 
         [0000]    
       
         
               
               
             
           
               
                   
               
               
                 row 
                 bit 
               
               
                   
               
             
             
               
                 0 
                 1:0 Line 0 pixel[1:0] 
               
               
                   
                 3:2 Line 1 pixel[1:0] 
               
               
                   
                 5:4 Line 2 pixel[1:0] 
               
               
                   
                 7:6 Line 3 pixel[1:0] 
               
               
                 1 
                 7:0 Line 0 pixel[9:2] 
               
               
                 2 
                 7:0 Line 1 pixel[9:2] 
               
               
                 3 
                 7:0 Line 2 pixel[9:2] 
               
               
                 4 
                 7:0 Line 3 pixel[9:2] 
               
               
                   
               
             
          
         
       
     
         [0053]    The following describes an algorithm that has been shown to compress on average over 75% of chunks in a typical high definition image. A chunk to be compressed consists of multiple 4×4 blocks. 
         [0054]    The algorithm uses a form of transformation to the frequency domain by attempting to fit the blocks to a set of surfaces. Each candidate surface represents one or more fundamental spacial frequencies and phases. Only two frequencies are considered in each dimension; ⅛ th  and ¼ th  of the pixel frequency. The theoretically highest frequency of ½ is ignored because, either it is unlikely to present in high definition and ultra-high definition images, or if it is present, it is unlikely that it can be losslessly compressed by a sufficient ratio. 
         [0055]    First the mean (M) of all of the pixels is calculated and the 0 th  order error terms are calculated. The combined size of the header and the variable length code encoding all of the error terms is then stored for the 0 th  order case. If this stage is used as the final result, the stored bits are T, M, {error terms}, where T is the 2 or 3 bit coding type. In this case T indicates 0 th  order coding. 
         [0056]    The algorithm then continues to the first order stage; 4×4 block  30  is subdivided into four 2×2 sub-blocks a  32 , b  34 , c  36  &amp; d  38 , as shown in  FIG. 4  and the mean pixel value for each of these is calculated using: 
         [0000]    
       
         
           
             M 
             = 
             
               
                 1 
                 16 
               
                
               
                 
                   ∑ 
                   
                     y 
                     = 
                     0 
                   
                   3 
                 
                  
                 
                   
                     ∑ 
                     
                       x 
                       = 
                       0 
                     
                     3 
                   
                    
                   
                     P 
                     yx 
                   
                 
               
             
           
         
       
       
         
           
             
               a 
               = 
               
                 
                   1 
                   4 
                 
                  
                 
                   
                     ∑ 
                     
                       y 
                       = 
                       0 
                     
                     1 
                   
                    
                   
                     
                       ∑ 
                       
                         x 
                         = 
                         0 
                       
                       1 
                     
                      
                     
                       P 
                       yx 
                     
                   
                 
               
             
             , 
             
               b 
               = 
               
                 
                   1 
                   4 
                 
                  
                 
                   
                     ∑ 
                     
                       y 
                       = 
                       0 
                     
                     1 
                   
                    
                   
                     
                       ∑ 
                       
                         x 
                         = 
                         2 
                       
                       3 
                     
                      
                     
                       P 
                       yx 
                     
                   
                 
               
             
             , 
             
               c 
               = 
               
                 
                   1 
                   4 
                 
                  
                 
                   
                     ∑ 
                     
                       y 
                       = 
                       2 
                     
                     3 
                   
                    
                   
                     
                       ∑ 
                       
                         x 
                         = 
                         0 
                       
                       1 
                     
                      
                     
                       P 
                       yx 
                     
                   
                 
               
             
             , 
             
               d 
               = 
               
                 
                   1 
                   4 
                 
                  
                 
                   
                     ∑ 
                     
                       y 
                       = 
                       2 
                     
                     3 
                   
                    
                   
                     
                       ∑ 
                       
                         x 
                         = 
                         2 
                       
                       3 
                     
                      
                     
                       P 
                       yx 
                     
                   
                 
               
             
           
         
       
       
         
           
             
               
                 S 
                 a 
               
               = 
               
                 sign 
                  
                 
                   ( 
                   
                     M 
                     - 
                     a 
                   
                   ) 
                 
               
             
             , 
             
               
                 S 
                 b 
               
               = 
               
                 sign 
                  
                 
                   ( 
                   
                     M 
                     - 
                     b 
                   
                   ) 
                 
               
             
             , 
             
               
                 S 
                 c 
               
               = 
               
                 sign 
                  
                 
                   ( 
                   
                     M 
                     - 
                     c 
                   
                   ) 
                 
               
             
             , 
             
               
                 S 
                 a 
               
               = 
               
                 sign 
                  
                 
                   ( 
                   
                     M 
                     - 
                     d 
                   
                   ) 
                 
               
             
             , 
           
         
       
     
         [0057]    The delta between each sub-block and M is calculated and a 2×2 sign map {S a , S b , S c , S d } is generated. There are 16 possible sign maps which can be divided into 4 classes (“unidirectional slope”, “corner impulse”, “diagonal”, and “impossible”). 
         [0058]    Some example surfaces (slope, impulse and diagonal) are shown in  FIGS. 6, 7, and 8 .  FIG. 6  is an “unidirectional slope” example. In each of the example surfaces, the figure&#39;s vertical axis represents the unweighted component delta  50  (the difference between the pixel component value at that position and a mean pixel value), horizontal image axis  52  represents 4 pixels along one dimension of the image (e.g. the horizontal dimension) and receding or vertical image axis  54  represents the other dimension of the image (e.g. the vertical dimension). The differing compressed blocks are identified below each figure. In this example the component deltas are increasing linearly in only one of the image dimensions. This case has two possible orientations each with positive or negative slope.  FIG. 7  is a “corner impulse” example. Here the component deltas are peaking in one corner of the 4×4 array. This case has four possible orientations each with positive or negative slope.  FIG. 8  is a “diagonal” example. Here the component deltas are peaking in along the diagonal of the 4×4 array. This case has two possible orientations each with positive or negative slope. 
         [0059]    After picking the coded surface (C) to use, the algorithm calculates a weighting factor (W) to apply to the surface using the mean of absolute differences. It then generates the 4×4 prediction and calculates the 1 st  order error terms. The combined size of the (now larger) header and the variable length code encoding all of the error terms is then stored for the first order case. In this case the compressed block would be stored as T, M, C 1 , W 1 , {error terms} where T indicates the coding type (first order in this case). C 1  and W 1  are all variable length coded encoded, noting that some surface types C are far more likely than others. 
         [0060]    The stage is then repeated as the second order stage. This performs the same calculations but uses the error terms from the first order stage as its input. This allows a bidirectional slope to be predicted with different gradients in each dimension. If this is successful, the block is stored as T, M, C 1 , W 1 , C 2 , W 2 , {error terms}. 
         [0061]    A simple example of the predicted surface after the second order stage is an arbitrary two-dimensional slope as shown in  FIG. 9 . 
         [0062]    For the third order stage the four 2×2 sub-blocks are re-calculated as shown in  FIG. 10 . Here, all the pixels e  40  are considered as one sub-block and similarly for the f  42  and g  44  pixels. 
         [0063]    There are sixteen possible sign maps, which can be divided into seven classes “flat”, “ridge”, “centre impulse”, “checker board”, “peak”, “saddle” and “impossible”. These preliminary maps are shown as follows: “ridge” in  FIG. 11 ; “centre impulse” in  FIG. 12 ; “checker board” in  FIG. 13 ; “peak” in  FIG. 14 , and “saddle” in  FIG. 15 . As with the previously disclosed surfaces, in each of the example surfaces, the figure&#39;s vertical axis represents the unweighted component delta  50  (the difference between the pixel component value at that position and a mean pixel value), horizontal image axis  52  represents 4 pixels along one dimension of the image (e.g. the horizontal dimension) and vertical image axis  54  represents the other dimension of the image (e.g. the vertical dimension). The differing compressed blocks are identified below each figure. 
         [0064]    The third order stage is then calculated the same way as the second order stage, taking the error terms of the second stage as its input. If this is successful, the block is stored as T, M, C 1 , W 1 , C 2 , W 2 , C 3 , W 3 , (error terms). 
         [0065]    A fourth order stage can be used where the surfaces represent the ½ frequencies but this may have almost no coding gain. 
         [0066]    Some coding gain is possible if other combinations using the third order stage are considered, e.g., T, M, C 3 , W 3 , (error terms) or T, M, C 1 , W 1 , C 3 , W 3 , (error terms). An example of a simple combination of a first order and third order surface (slope plus ridge) is shown in  FIG. 16 . An example of an arbitrary surface possibly with three stages is shown in  FIG. 17 . 
         [0067]    For subsequent blocks in a chunk, the M value is coded differentially from the previous block. Depending on the previous block&#39;s coding type, the new M value is also predicted from the previous using the slope direction and weighting factor before encoding the difference. For interleaved chroma data, an initial absolute M is used for each component. This disclosure is not intended to be limited to the surfaces presented. Other surfaces are intended to be included with different or additional sign maps. 
         [0068]    The bitstream is a sequence of variable size symbols. The size of each symbol is determined by the context and the symbol itself. Symbols are packed into bytes left-justified. Bytes are stored in little endian order (first byte at the lowest byte address). This may appear as an unusual combination of big and little endian ordering, but is entirely consistent with how Motion Picture Experts Group (MPEG) bitstreams are stored in systems operating in little endian byte order. The bitstream syntax is defined by the following pseudocode: 
         [0000]    
       
         
               
             
               
               
             
               
             
               
               
             
               
             
               
               
             
               
             
               
               
               
             
               
             
               
               
             
               
             
               
               
               
             
               
             
               
               
             
               
               
               
             
               
               
             
               
               
             
               
               
               
             
               
               
             
               
               
             
               
             
               
               
             
               
               
               
             
               
               
             
               
             
           
               
                   
               
             
             
               
                 compressed_chunk { 
               
               
                  first_block 
               
               
                  for (i=1; i&lt;NUM_BLOCKS_PER_CHUNK; i++) { 
               
             
          
           
               
                   
                 block 
               
             
          
           
               
                  } 
               
               
                 } 
               
               
                 first_block { 
               
             
          
           
               
                  type 
                 2 bits 
               
               
                  mean 
                 8 or 10 bits 
               
             
          
           
               
                  surfaces 
               
               
                  errors 
               
               
                 } 
               
               
                 block { 
               
             
          
           
               
                  repeat 
                 1 bit 
               
             
          
           
               
                  if (repeat==0) { 
               
             
          
           
               
                   
                 type 
                 2 bits (Table 5 Type Codes) 
               
             
          
           
               
                  } 
               
               
                  delta_mean 
               
               
                  surfaces 
               
               
                  errors 
               
               
                 } 
               
               
                 delta_mean { 
               
             
          
           
               
                  magnitude 
                 VLC (Table 1 Weighting Factor 
               
               
                   
                 Codes) 
               
             
          
           
               
                  if (magnitude != 0) { 
               
             
          
           
               
                   
                 sign 
                 1 bit (0=positive, 1=negative) 
               
             
          
           
               
                  } 
               
               
                 } 
               
               
                 surfaces { 
               
             
          
           
               
                  for (i=0; i&lt;num_surfaces; i++) { 
                 See Table 5 Type Codes for 
               
               
                   
                 num_surfaces 
               
             
          
           
               
                   
                 weighting_factor 
                 VLC (Table 1 Weighting Factor 
               
             
          
           
               
                   
                 Codes) 
               
             
          
           
               
                   
                 if ((weighting_factor != 0) &amp;&amp; (repeat == 0)) { 
               
             
          
           
               
                   
                  sign_map_code 
                 VLC (Table 3 Sign Map 
               
             
          
           
               
                   
                 Codes A) 
               
             
          
           
               
                   
                 } 
               
             
          
           
               
                  } 
               
               
                 } 
               
               
                 errors { 
               
               
                  for (y=0; y&lt;4; y++) { 
               
             
          
           
               
                   
                 for (x=0; x&lt;4; x++) { 
               
             
          
           
               
                   
                  error[y][x] 
                 VLC (Table 2 Error Term Codes) 
               
             
          
           
               
                   
                 } 
               
             
          
           
               
                  } 
               
               
                 } 
               
               
                   
               
             
          
         
       
     
         [0069]    When a chunk is not compressed, the raw pixel data is reordered within the bitstream to be more consistent with the dataflow of compressed chunks. The bitstream syntax is defined by the following pseudocode: 
         [0000]    
       
         
               
               
             
               
               
             
               
               
             
               
               
             
               
               
               
             
               
               
             
               
               
             
           
               
                   
                   
               
             
             
               
                   
                 uncompressed_chunk { 
               
               
                   
                  for (i=0; i&lt;NUM_BLOCKS_PER_CHUNK; i++) { 
               
             
          
           
               
                   
                 uncompressed_block 
               
             
          
           
               
                   
                  } 
               
               
                   
                 } 
               
               
                   
                 uncompressed_block { 
               
               
                   
                  for (y=0; y&lt;4; y++) { 
               
             
          
           
               
                   
                 for (x=0; x&lt;4; x++) { 
               
             
          
           
               
                   
                  pixel[y][x] 
                 8 or 10 bit pixel 
               
             
          
           
               
                   
                 } 
               
             
          
           
               
                   
                  } 
               
               
                   
                 } 
               
               
                   
                   
               
             
          
         
       
     
         [0070]    To support lossless compression it is assumed that some chunks cannot be compressed at all and, therefore, there is no coding space left within a chunk to indicate whether it is compressed or not. Therefore, the compression indication is stored out-of-band, meaning that the information is stored elsewhere. 
         [0071]    The compression indicator is a two bit field per chunk, indicating that the chunk is not compressed, compressed to 50%, 75% or 87.5%. 
         [0072]    A possible alternative mechanism where the 87.5% indication is not required, would be to store five three-way indicators per eight bits, thereby reducing the out-of-band storage requirement by 20%. 
         [0073]    An instance of the engine is intended to be located at each client device. This is preferable to locating a general purpose instance of it in the memory controller due to the differing requirements of each device. The video decoder requires aligned ordered block write access and independent unaligned random block read access, the display pipeline (CPIPE) requires ordered scanline read access. 
         [0074]    The memory-based video processor used for scaling the video also requires ordered scanline read access, but does not require any compressed write access despite being a memory to memory processor. This is because it either operates in a streaming mode (where the output is streamed directly to the display pipeline (CPIPE) or because it only writes back to memory when downscaling by a factor of two or more, and then the downscaling has effectively reduced the bandwidth to less than 25% making compression redundant. 
         [0075]    Aligned ordered block writes are the easiest to handle because they can be naturally compressed as a unit and because blocks are stored linearly in main memory. Therefore, no additional buffering is required. As the block arrives at the compressor, it gets compressed and then it is written to memory using a single memory transaction. Writes are inherently simpler than reads because the compressed size is known at the time that memory transaction is requested. 
         [0076]    Random block reads are the next easiest to handle because again they can be naturally decompressed as a unit, and because blocks are stored linearly in main memory. However, the video decoder requires unaligned block access and variable block sizes to handle motion compensation. This problem is addressed by the video decoder&#39;s block-based read cache which converts unaligned requests into fixed size aligned requests. The excess pixel data fetched due to the realignment and resizing is kept in the cache and has a reasonably high probability of being required in a subsequent random access. 
         [0077]    Ordered scanline reads require a change to the system to operate efficiently because at least three additional scanlines worth of data must be buffered before the first pixel becomes available. Without this buffering the bandwidth would increase, not decrease, because blocks would have to be repeatedly reread and decompressed. The basic system architecture is shown in  FIG. 18 .  FIG. 18  only shows the flow of pixels when operating in a bandwidth compression mode, there are bypasses available to avoid compression if necessary. 
         [0078]    Video decoder  100 , such as a high definition/ultra high definition video decoder, uses an on-chip 2D cache  102  to improve memory efficiency when reading arbitrary two dimension blocks of pixels  104 . Due to the random access nature of pixel reads, the sideband information used to store the compression level (none/50%/75%) must be buffered to avoid reducing memory efficiency. Each reference frame at 4K resolution (3840×2160) with 32×4 pixel blocks requires 12 KB of storage for single level compression (none/50%) and 24 KB for multi-level compression (none/50%/75%). The maximum number of frames in use at a time is 6, totaling 72 KB or 144 KB of on-chip storage. 
         [0079]    Memory Based Video Processor  108  will operate in one of three modes:
       Bypass Memory Based Video Processor  108 , no scaling required, so no processing required by Memory Based Video Processor  108 ;   Partial downscale, scaling required but by a ratio less than but close to 1 whereby Memory Based Video Processor  108  receives decompressed pixels  110 , downscales them  112  and streams them  114  to video pipeline  116 ; and   Full downscale, significant scaling required that implies output  120  must be written back to main memory  122  because Memory Based Video Processor  108  cannot keep up with the input data rate required to stream the output to video pipeline  116 . However at these ratios the output bandwidth is much lower and therefore compression is of reduced value. In this mode video pipeline  116  receives downscaled uncompressed pixels  124 .       
 
         [0083]    In either mode (ignoring the bypass mode) Memory Based Video Processor  108  receives decompressed pixels from the decompressor  106 . However to avoid having to reread blocks, the blocks are stored in a buffer  126  equivalent to at least 3 scanlines in size. Memory Based Video Processor  108  cannot start receiving pixels until entire buffer  126  has been filled with decompressed pixels. 
         [0084]    Video pipeline or display pipeline (CPIPE)  116  will only accept decompressed pixels  110  from memory  122  when Memory Based Video Processor  108  is in bypass mode (no scaling). In this mode it will decompress in the same manner as described above for Memory Based Video Processor  108  using a similar buffer  126 . 
         [0085]    It may well be possible to avoid needing decompressor  106  before display pipeline (CPIPE)  116  if the no-scaling case also passes through Memory Based Video Processor  108 , with Memory Based Video Processor  108  performing no processing but just providing a path to go through its decompressor  106 . 
       Microarchitecture 
       [0086]    The Decompressor Data Engine (DDE) accepts compressed input data and commands and generates decompressed output data. It is not concerned with memory addressing or buffer formats. The engine operates on individual chunks of data, where a chunk represents a single component (Y, Cb or Cr) of a 2D array of pixels. In this description a “pixel” refers to just one component part of a pixel. 
         [0087]    The input data is a sequence of data words containing the compressed bitstream. The number of data words that it expects is determined by the command. Note that while the number of useful bits in the bitstream is variable, the bitstream data is always data word aligned and always an integer number of data words, implying that it may be padded with unused trailing data. The word size is configurable. 
         [0088]    The output data is a sequence of data words containing packed decompressed pixel components. The number of data words to expect is determined by the command. Note that the pixel data is always word aligned, there are always an integer number of pixels in a word, and always an integer number of data words in a sequence. The number of pixel components in a word is configurable and the number of bits per pixel is configurable. The engine can operate in reduced bits per pixel modes where the least significant bits of each pixel will be padded with zeros. For example if the configuration is ten bits per pixel then it will also support 8 bits per pixel with 2 bits of padding. The default configuration is sixty-four bit input, ten bits per pixel, and four pixels per output word (forty bit output). 
         [0089]    The input bitstream is a continuous stream of variable size symbols. The output is a sequence of pixels in scanline order within each block, i.e. the pixels are output in 4×4 blocks from left to right and from left to right, and then top to bottom within the block. The pixels are presented in little endian order, i.e. the leftmost pixel is in the least significant part of the word. The engine has no knowledge of the frame buffer format, the pitch of the buffer, the chunk organization, the pixel storage format, how different pixel components are related, etc. 
         [0090]    The Decompressor Data Engine (DDE) supports the following commands: 
         [0000]    
       
         
               
               
               
             
           
               
                   
               
             
             
               
                 0 
                 DDE_CMD_32_4_8_PASSTHRU 
                 Passthrough uncompressed 32x4 8bpp pixel chunk 
               
               
                 1 
                 DDE_CMD_32_4_8_50 
                 Decompress 50% compressed 32x4 8bpp pixel chunk 
               
               
                 2 
                 DDE_CMD_32_4_8_75 
                 Decompress 75% compressed 32x4 8bpp pixel chunk 
               
               
                 3 
                 Reserved 
                   
               
               
                 4 
                 DDE_CMD_32_4_10_PASSTHRU 
                 Passthrough uncompressed 32x4 10bpp pixel chunk 
               
               
                 5 
                 DDE_CMD_32_4_10_50 
                 Decompress 50% compressed 32x4 10bpp pixel chunk 
               
               
                 6 
                 DDE_CMD_32_4_10_75 
                 Decompress 75% compressed 32x4 10bpp pixel chunk 
               
               
                 7 
                 Reserved 
               
               
                   
               
             
          
         
       
     
         [0091]      FIG. 19  is a block diagram that shows the dataflow inside the Decompressor Data Engine (DDE). 
         [0092]    Bitstream unpacker  202  removes successfully decoded symbols from data input FIFO  200  bitstream input. VLC decoder  204  decodes the various symbols based on the context and prediction  216 . Surface reconstructor  206  takes the decoded symbols and constructs the initial surface. On subsequent passes, it constructs additional surfaces  208  to be accumulated  210 . After all the surfaces have been added together the final output is error compensated  212  and added to the queue of completed blocks  214  to data output FIFO  218 . 
         [0093]      FIG. 20  is a flow chart that shows the control flow in the decompressor. The process blocks are clock cycle stages and the conditional blocks are combinational logic. The values shown in square brackets are data dependent and may or may not be present and may have been processed in the previous cycle. 
         [0094]    The Compressor Data Engine (CDE) accepts uncompressed input data and commands and generates compressed output data. It is not concerned with memory addressing or buffer formats. The engine operates on individual chunks of data, where a chunk represents a single component (Y, Cb or Cr) of a 2D array of pixels. In this description a “pixel” refers to just one component part of a pixel. 
         [0095]    The output data is a sequence of data words containing the compressed bitstream. The number of data words to expect is implied by the value in the status word. Note that while the number of useful bits in the bitstream is variable, the bitstream data is always data word aligned, and always an integer number of data words, implying that it may be padded with unused trailing data. The word size is configurable. 
         [0096]    The input data is a sequence of data words containing packed uncompressed pixel components. The number of data words to expect is determined by the command. Note that the pixel data is always word aligned, there are always an integer number of pixels in a word, and always an integer number of data words in a sequence. The number of pixel components in a word is configurable and the number of bits per pixel is configurable. The engine can operate in reduced bits per pixel modes where the least significant bits of each pixel should be padded with zeros. For example if the configuration is ten bits per pixel then it will also support eight bits per pixel with two bits of padding. The default configuration is four pixels per input word, ten bits per pixel (forty bit input), and sixty-four bit output word. 
         [0097]    The output bitstream is a continuous stream of variable size symbols. The input is a sequence of pixels in scanline order within each 4×4 block, i.e. the pixels are input in blocks from left to right and from left to right, and then top to bottom within the block. The pixels are presented in little endian order, i.e. the leftmost pixel is in the least significant part of the word. The engine has no knowledge of the frame buffer format, the pitch of the buffer, the chunk organization, the pixel storage format, how different pixel components are related, etc. 
         [0098]    The Compressor Data Engine (CDE) supports the following commands: 
         [0000]    
       
         
               
               
               
             
           
               
                   
               
               
                 Value 
                 Name 
                 Description 
               
               
                   
               
             
             
               
                 0 
                 CDE_CMD_32_4_8 
                 Compress a 32x4 8bpp pixel chunk 
               
               
                 1 
                 CDE_CMD_32_4_10 
                 Compress a 32x4 10bpp pixel chunk 
               
               
                 Status 
               
               
                   
               
             
          
         
       
     
         [0099]    The Compressor Data Engine (CDE) generates the following status: 
         [0000]    
       
         
               
               
               
             
               
               
               
             
           
               
                   
               
               
                 Value 
                 Name 
                 Description 
               
               
                   
               
             
             
               
                   
               
             
          
           
               
                 0 
                 CDE_STATUS_IDLE 
                 Engine is idle 
               
               
                 1 
                 CDE_STATUS_BUSY 
                 Engine is busy on intermediate cycle of a chunk 
               
               
                 2 
                 CDE_STATUS_LAST 
                 Engine is on the last cycle of a chunk 
               
               
                 8 
                 CDE_STATUS_32_4_8_PASSTHRU 
                 First cycle of 32x4 8bpp pixel chunk that was 
               
               
                   
                   
                 not compressed 
               
               
                 9 
                 CDE_STATUS_32_4_8_50 
                 First cycle of 32x4 8bpp pixel chunk that was 
               
               
                   
                   
                 compressed to 50% 
               
               
                 10 
                 CDE_STATUS_32_4_8_75 
                 First cycle of 32x4 8bpp pixel chunk that was 
               
               
                   
                   
                 compressed to 75% 
               
               
                 11 
                 Reserved 
                   
               
               
                 12 
                 CDE_STATUS_32_4_10_PASSTHRU 
                 First cycle of 32x4 10bpp pixel chunk that was 
               
               
                   
                   
                 not compresssed 
               
               
                 13 
                 CDE_STATUS_32_4_10_50 
                 First cycle of 32x4 10bpp pixel chunk that was 
               
               
                   
                   
                 compressed to 50% 
               
               
                 14 
                 CDE_STATUS_32_4_10_75 
                 First cycle of 32x4 10bpp pixel chunk that was 
               
               
                   
                   
                 compressed to 75% 
               
               
                 15 
                 Reserved 
               
               
                   
               
             
          
         
       
     
         [0100]    The status word is valid on every cycle but is also flow controlled by the data flow control, i.e. the “first” status indication does not change until the input data is valid and accepted, and the “last” status indication does not change until the last output data is valid and accepted. 
         [0101]      FIG. 21  is a block diagram showing the dataflow inside the Compressor Data Engine (CDE) 
         [0102]    Block queue  302  assembles incoming data  300  into the appropriate 4×4 blocks suitable for parallel processing. Mean unit  306  calculates the mean of the incoming block (the 0 th  order surface) which is then used by the comparator in sign map  304  to generate the code for the best surface which is then used construct the 1st order surface  308 . Subsequent order surfaces are accumulated  312  and compared with the original block to generate error terms  314 . The error block is then fed back  324  to generate the codes for the higher order surfaces. After each pass the results are stored in candidate array  316  and the total VLC size is encoded and calculated  318 . On completing all necessary passes, the best candidate from the candidate array is chosen to be used in the actual bitstream generation  320  for data output  322 . Subsequent blocks within a chunk use the prediction unit  310  to predict the mean and surface type coding from the previous block. 
         [0103]    Below are the Tables referred to above: 
         [0000]    Weighting factors are coded as shown in the following tables: 
         [0000]                        TABLE 1               Value   VLC                   0   1       1   01       2   001       3   00010       4   00011       5   0000100       6   0000101       7   0000110       8   0000111        9-16   000001000-           000001111       17-32   00000010000-           00000011111       33-64   0000000100000-           0000000111111        65-128   000000001000000-           000000001111111       129-256   00000000010000000-           00000000011111111       257-512   0000000000100000000-           0000000000111111111        513-1024   000000000001000000000-           000000000001111111111                    
If a weighting factor is zero, the corresponding sign map code is skipped.
 
Error terms are coded as follows:
 
         [0000]                                      TABLE 2               Value   VLC                   0   10       1   11s       2   010s       3   011s       4   0010s       5   0011s       6   000100s       7   000101s       8   000110s       9   000111s       10-17   00001000s-           00001111s       18-33   0000010000s-           0000011111s       34-65   000000100000s-           000000111111s        66-129   00000001000000s-           00000001111111s       130-257   0000000010000000s-           0000000011111111s       258-513   000000000100000000s-           000000000111111111s        514-1025   00000000001000000000s-           00000000001111111111s            No errors   0000000001   8 bit mode only       No errors   000000000001   10 bit mode only                    
For non-zero values, the s bit is the sign.
 
The “no errors” cases are used to encode the situation where all 16 errors are zero.
 
The error terms for 12 bit video are not shown above.
 
       Sign Map Codes A 
       [0104]    These codes are used for C in orders 1 and 2. The occurrence of the “slope” type surface was found to far outweigh the other types. 
         [0000]    
       
         
               
               
               
               
               
             
               
               
               
               
               
             
           
               
                 TABLE 3 
               
               
                   
               
               
                   
                 Map 
                 Code 
                 VLC 
                 Comment 
               
               
                   
               
             
             
               
                   
               
             
          
           
               
                 + 
                 + 
                 0000 
                 001000 
                 Flat 
               
               
                 + 
                 + 
                   
                   
                   
               
               
                 − 
                 + 
                 0001 
                 0100 
                 Corner impulse 
               
               
                 + 
                 + 
                   
                   
                   
               
               
                 + 
                 − 
                 0010 
                 0101 
                 Corner impulse 
               
               
                 + 
                 + 
                   
                   
                   
               
               
                 − 
                 − 
                 0011 
                 100 
                 Slope 
               
               
                 + 
                 + 
                   
                   
                   
               
               
                 + 
                 + 
                 0100 
                 0110 
                 Corner impulse 
               
               
                 − 
                 + 
                   
                   
                   
               
               
                 − 
                 + 
                 0101 
                 101 
                 Slope 
               
               
                 − 
                 + 
                   
                   
                   
               
               
                 + 
                 − 
                 0110 
                 001001 
                 Diagonal 
               
               
                 − 
                 + 
                   
                   
                   
               
               
                 − 
                 − 
                 0111 
                 001010 
                 Corner impulse 
               
               
                 − 
                 + 
                   
                   
                   
               
               
                 + 
                 + 
                 1000 
                 0111 
                 Corner impulse 
               
               
                 + 
                 − 
                   
                   
                   
               
               
                 − 
                 + 
                 1001 
                 001011 
                 Diagonal 
               
               
                 + 
                 − 
                   
                   
                   
               
               
                 + 
                 − 
                 1010 
                 110 
                 Slope 
               
               
                 + 
                 − 
                   
                   
                   
               
               
                 − 
                 − 
                 1011 
                 001100 
                 Corner impulse 
               
               
                 + 
                 − 
                   
                   
                   
               
               
                 + 
                 + 
                 1100 
                 111 
                 Slope 
               
               
                 − 
                 − 
                   
                   
                   
               
               
                 − 
                 + 
                 1101 
                 001101 
                 Corner impulse 
               
               
                 − 
                 − 
                   
                   
                   
               
               
                 + 
                 − 
                 1110 
                 001110 
                 Corner impulse 
               
               
                 − 
                 − 
                   
                   
                   
               
               
                 − 
                 − 
                 1111 
                 001111 
                 Impossible 
               
               
                 − 
                 − 
               
               
                   
               
             
          
         
       
     
       Sign Map Codes B 
       [0105]    These codes are used for C in order 3. The occurrence of the “ridge” type surface was found to far outweigh the other types. 
         [0000]    
       
         
               
               
               
               
               
             
               
               
               
               
               
             
           
               
                 TABLE 4 
               
               
                   
               
               
                   
                 Map 
                 Code 
                 VLC 
                 Comment 
               
               
                   
               
             
             
               
                   
               
             
          
           
               
                 + 
                 + 
                 0000 
                 001000 
                 Flat 
               
               
                 + 
                 + 
                   
                   
                   
               
               
                 − 
                 + 
                 0001 
                 0100 
                 Centre Impulse 
               
               
                 + 
                 + 
                   
                   
                   
               
               
                 + 
                 − 
                 0010 
                 0101 
                 Saddle 
               
               
                 + 
                 + 
                   
                   
                   
               
               
                 − 
                 − 
                 0011 
                 100 
                 Ridge 
               
               
                 + 
                 + 
                   
                   
                   
               
               
                 + 
                 + 
                 0100 
                 0110 
                 Saddle 
               
               
                 − 
                 + 
                   
                   
                   
               
               
                 − 
                 + 
                 0101 
                 101 
                 Ridge 
               
               
                 − 
                 + 
                   
                   
                   
               
               
                 + 
                 − 
                 0110 
                 001001 
                 Checker Board 
               
               
                 − 
                 + 
                   
                   
                   
               
               
                 − 
                 − 
                 0111 
                 001010 
                 Peak 
               
               
                 − 
                 + 
                   
                   
                   
               
               
                 + 
                 + 
                 1000 
                 0111 
                 Peak 
               
               
                 + 
                 − 
                   
                   
                   
               
               
                 − 
                 + 
                 1001 
                 001011 
                 Checker Board 
               
               
                 + 
                 − 
                   
                   
                   
               
               
                 + 
                 − 
                 1010 
                 110 
                 Ridge 
               
               
                 + 
                 − 
                   
                   
                   
               
               
                 − 
                 − 
                 1011 
                 001100 
                 Saddle 
               
               
                 + 
                 − 
                   
                   
                   
               
               
                 + 
                 + 
                 1100 
                 111 
                 Ridge 
               
               
                 − 
                 − 
                   
                   
                   
               
               
                 − 
                 + 
                 1101 
                 001101 
                 Saddle 
               
               
                 − 
                 − 
                   
                   
                   
               
               
                 + 
                 − 
                 1110 
                 001110 
                 Centre Impulse 
               
               
                 − 
                 − 
                   
                   
                   
               
               
                 − 
                 − 
                 1111 
                 001111 
                 Impossible 
               
               
                 − 
                 − 
               
               
                   
               
             
          
         
       
     
       Header Coding 
     Type Coding 
       [0106]    The following table lists the values for the type code T: 
       First Block of a Chunk: 
       [0107]      
         [0000]                                                                          TABLE 5                   T   Code   Stages                                    0   00   0           1   01   0, 1           2   10   0, 1, 2           3   11   0, 1, 2, 3            Subsequent blocks:                0   000   0           1   001   0, 1           2   010   0, 1, 2           3   011   0, 1, 2, 3           4   1   Repeat previous                    
T=4 is used to encode relative blocks where the type code and all the active sign map codes are identical to the previous block.
 
       Industrial Examples 
       [0108]    These tests were performed with 3 rd  order surface mapping, single level (50% cutoff) and dual level compression (50%/75%), and 32×4 8-bit pixel chunks. The percentages are the bandwidth required compared to normal. 
         [0000]    
       
         
               
               
               
               
               
             
           
               
                 TABLE 6 
               
               
                   
               
               
                   
                   
                 BW 
                 BW 
                   
               
               
                   
                   
                 (50% 
                 (75% 
                   
               
               
                 File 
                 Size 
                 cutoff) 
                 cutoff) 
                 Comments 
               
               
                   
               
             
             
               
                 lake.jpg 
                 1920 × 1080 
                 78.0% 
                 72.3% 
                 JPEG photo with lots of 
               
               
                   
                   
                   
                   
                 high frequency detail 
               
               
                 gun.jpg 
                 1920 × 1080 
                 83.2% 
                 74.5% 
                 JPEG photo with lots of 
               
               
                   
                   
                   
                   
                 in-focus detail 
               
               
                 lots.jpg 
                 1920 × 1080 
                 72.8% 
                 63.3% 
                 Grainy film 
               
               
                 fraiser.jpg 
                 1920 × 1080 
                 55.2% 
                 53.5% 
                 Typical HDTV frame 
               
               
                   
                   
                   
                   
                 grab 
               
               
                 ski.jpg 
                 1920 × 1080 
                 79.3% 
                 70.7% 
                 1080p video grab (from 
               
               
                   
                   
                   
                   
                 8.3 Mbps WMV) 
               
               
                 climb.jpg 
                 1920 × 1080 
                 62.4% 
                 57.1% 
                 1080p video grab (from 
               
               
                   
                   
                   
                   
                 8.3 Mbps WMV) 
               
               
                 run.jpg 
                 1920 × 1080 
                 64.8% 
                 61.2% 
                 1080p video grab (from 
               
               
                   
                   
                   
                   
                 8.3 Mbps WMV) 
               
               
                 mermaid.jpg 
                 1920 × 1080 
                 58.9% 
                 55.6% 
                 Sharp photo with soft 
               
               
                   
                   
                   
                   
                 background 
               
               
                 chase.jpg 
                 1920 × 1080 
                 59.8% 
                 55.5% 
                 High motion with 
               
               
                   
                   
                   
                   
                 macroblocking effects 
               
               
                   
                   
                   
                   
                 from letterboxed 1080p 
               
               
                   
                   
                   
                   
                 video (8.3 Mbps WMV) 
               
               
                 woods.jpg 
                 1920 × 1080 
                 99.3% 
                 91.6% 
                 Very high quality, high 
               
               
                   
                   
                   
                   
                 detail JPEG photo with 
               
               
                   
                   
                   
                   
                 no compression 
               
               
                   
                   
                   
                   
                 artifacts 
               
               
                 maria.jpg 
                 1920 × 1200 
                 75.5% 
                 64.2% 
                 High quality JPEG photo 
               
               
                 testcard.jpg 
                 1920 × 1080 
                 61.6% 
                 58.1% 
                 HD Test pattern 
               
               
                 blossom.jpg 
                 1920 × 1200 
                 76.6% 
                 75.6% 
                 High quality JPEG photo 
               
               
                   
                   
                 71.3% 
                 65.6% 
                 Average 
               
               
                   
               
             
          
         
       
     
         [0109]    While various embodiments of the disclosed method and apparatus have been described above, it should be understood that they have been presented by way of example only, and should not limit the claimed invention. Likewise, the various diagrams may depict an example architectural or other configuration for the disclosed method and apparatus. This is done to aid in understanding the features and functionality that can be included in the disclosed method and apparatus. The claimed invention is not restricted to the illustrated example architectures or configurations, rather the desired features can be implemented using a variety of alternative architectures and configurations. Indeed, it will be apparent to one of skill in the art how alternative functional, logical or physical partitioning and configurations can be implemented to implement the desired features of the disclosed method and apparatus. Also, a multitude of different constituent module names other than those depicted herein can be applied to the various partitions. Additionally, with regard to flow diagrams, operational descriptions and method claims, the order in which the steps are presented herein shall not mandate that various embodiments be implemented to perform the recited functionality in the same order unless the context dictates otherwise. 
         [0110]    Although the disclosed method and apparatus is described above in terms of various exemplary embodiments and implementations, it should be understood that the various features, aspects and functionality described in one or more of the individual embodiments are not limited in their applicability to the particular embodiment with which they are described. Thus, the breadth and scope of the claimed invention should not be limited by any of the above-described exemplary embodiments. 
         [0111]    Terms and phrases used in this document, and variations thereof, unless otherwise expressly stated, should be construed as open ended as opposed to limiting. As examples of the foregoing: the term “including” should be read as meaning “including, without limitation” or the like; the term “example” is used to provide exemplary instances of the item in discussion, not an exhaustive or limiting list thereof; the terms “a” or “an” should be read as meaning “at least one,” “one or more” or the like; and adjectives such as “conventional,” “traditional,” “normal,” “standard,” “known” and terms of similar meaning should not be construed as limiting the item described to a given time period or to an item available as of a given time, but instead should be read to encompass conventional, traditional, normal, or standard technologies that may be available or known now or at any time in the future. Likewise, where this document refers to technologies that would be apparent or known to one of ordinary skill in the art, such technologies encompass those apparent or known to the skilled artisan now or at any time in the future. 
         [0112]    A group of items linked with the conjunction “and” should not be read as requiring that each and every one of those items be present in the grouping, but rather should be read as “and/or” unless expressly stated otherwise. Similarly, a group of items linked with the conjunction “or” should not be read as requiring mutual exclusivity among that group, but rather should also be read as “and/or” unless expressly stated otherwise. Furthermore, although items, elements or components of the disclosed method and apparatus may be described or claimed in the singular, the plural is contemplated to be within the scope thereof unless limitation to the singular is explicitly stated. 
         [0113]    The presence of broadening words and phrases such as “one or more,” “at least,” “but not limited to” or other like phrases in some instances shall not be read to mean that the narrower case is intended or required in instances where such broadening phrases may be absent. The use of the term “module” does not imply that the components or functionality described or claimed as part of the module are all configured in a common package. Indeed, any or all of the various components of a module, whether control logic or other components, can be combined in a single package or separately maintained and can further be distributed in multiple groupings or packages or across multiple locations. 
         [0114]    Additionally, the various embodiments set forth herein are described in terms of exemplary block diagrams, flow charts and other illustrations. As will become apparent to one of ordinary skill in the art after reading this document, the illustrated embodiments and their various alternatives can be implemented without confinement to the illustrated examples. For example, block diagrams and their accompanying description should not be construed as mandating a particular architecture or configuration. 
         [0115]    Several embodiments are specifically illustrated and/or described herein. However, it will be appreciated that modifications and variations of the disclosed embodiments are covered by the above teachings and within the purview of the appended claims without departing from intended scope of the invention.