Abstract:
Methods and apparatus for conducting motion searching are provided. A first 2D array includes interconnected multi-directional shift registers for storing and shifting image values corresponding to a search window within a search region. A second 2D array includes registers for storing image values corresponding to a macroblock. A distortion calculation module is arranged to calculate and output a distortion value corresponding to the difference between image values stored in associated registers of the first and second arrays. The distortion value quantifies the correlation between the search window and the macroblock. The shift registers of the first 2D array are controlled to pass image values between adjacent shift registers to translate the position of the search window within the search region. Distortion values outputted after progressive shifts of the first 2D array are tracked to determine an optimal registration position of the macroblock relative to the search region.

Description:
FIELD OF THE INVENTION 
       [0001]    The present invention relates generally to video compression techniques. In particular, the present invention relates to a method and apparatus for improved motion estimation/search. 
       BACKGROUND OF THE INVENTION 
       [0002]    Digital video transmission, in particular streaming over communication channels such as over the Internet generally requires the video to be encoded prior to transmission. It is preferably to be able to compress digital video in a way that minimises bandwidth usage, whilst at the same time can deliver smooth video of an adequate quality. 
         [0003]    A number of widely used standards exist, such as MPEG-1 and MPEG-2, which specify the form of digital video encoding. However, these standards do not constrain every aspect of converting image sequences of digital video between uncompressed and compressed formats. One of a number of proprietary functions may be implemented within the framework of these established standards. As such, there is an opportunity for the design of encoder methods and systems to be modified and improved. 
         [0004]    One area of digital video encoding is intra-frame coding in which compression is applied to the information of a single frame of a video image sequence. This generally includes the application of techniques known in the art such as;
       a) shifting the frame from the RGB into the YCbCr colour space and reducing the chrominance information by up to a quarter;   b) applying a DCT to the frame and applying a quantisation matrix;   c) run-length amplitude/variable length coding the frame; and   d) using rate control to prevent buffer underflow/overflow.       
 
         [0009]    Another area of digital video encoding is inter-frame coding in which similarities between a series of image sequences (i.e. the temporal redundancies) are exploited. In particular, an encoder can forward predict a future frame (P-frames) from a starting intra-frame (or I frames). In addition, bi-directional interpolated prediction frames (B-frames) can be used to forward and backward interpolate the frames of a video sequence. In each case, encoding the temporal prediction information generally involves the use of a technique known as motion estimation. 
         [0010]    Motion estimation involves comparing frames in a sequence and representing the change between the frames such that only the portions that are different from one frame to another need be transmitted. This analysis involves determining how portions of an image may have moved over time, between frames—a so-called ‘motion search’ or ‘motion estimation’. For example, for a video sequence showing an airplane moving across a uniformly blue sky, a motion search will be conducted to determine how the portion of the image containing the airplane changes from one frame to the next. If a video sequence involves a camera-pan of a stationary environment, for example of a garden, then there will be uniform change in displacement of almost every image portion in the same direction. If the video to be encoded displays players on a sports field heading in different directions at different speeds, each portion of one frame to the next will need to be tracked individually. In all cases, determining how individual image portions have moved allows as much image information as possible to be carried forward from one video frame to the next, reducing the amount of ‘new’ information that needs to be transmitted. 
         [0011]    A macroblock represents a fundamental ‘portion’ of a video frame. Macroblocks are usually 16×16 pixels in size, although other block sizes (e.g. 8×16, 16×8, 8×8, 4×8, 8×4, and 4×4) are possible by regularly sub-dividing the fundamental 16×16 macroblock. Motion search is conducted within the YCbCr colour space on each luminance macroblock, one macroblock at a time, starting at the top left-hand macroblock, proceeding row-wise left to right, then top to bottom. For each macroblock, a two-dimensional spatial search is carried out to determine how each macroblock has changed its position over a series of frames. The change in the position of a macroblock from one frame to the next is encoded as a motion vector. Thus motion vectors can be used in mapping the spatial displacement of macroblocks from one video frame to the next. 
         [0012]    How this spatial search is conducted is one of the aspects not constrained by the MPEG-1 or 2 standards, and this is the subject matter to which the present invention particularly relates. 
         [0013]    When conducting a search, it is necessary to determine whether a good enough match has been made between one macroblock and the next. The quality of a match may be determined by calculating the difference between two macroblocks. One well-known measure of the difference is termed the ‘sum of absolute differences’ (SAD) the result of which is generally referred to as ‘distortion’. A challenge is to find the minimum distortion that will yield the appropriate motion vector for a given macroblock. 
         [0014]    The spatial search is usually confined to a small area surrounding the macroblock for which is search is being carried out. This is because it is computationally too expensive for an encoder to search the entirety of a frame for a match—especially if encoding needs to be performed in real-time. In addition, since larger motion vectors can take up significantly more bandwidth than smaller motion vectors, it can be better to transmit a smaller motion vector to a relatively distorted match than a larger motion vector to a better match. 
         [0015]    For this reason, the conventional range of possible movement of a macroblock from one frame to the next is confined. For example, a standard 16×16 macroblock is generally confined to +/−16 pixels in the vertical and horizontal directions—corresponding to a search area of 48×48 pixels or a 33×33 search extent. In a so-called ‘exhaustive motion search’, every location within the 33×33 search extent is searched and the result yielding the minimum distortion is selected. 
         [0016]    Whilst the exhaustive motion search is comprehensive, it is not necessarily considered to be appropriate for applications for which the efficiency of encoding is a priority. As a result, less comprehensive motion searches that yield relatively good results tend to be more desirable. An example of such a non-comprehensive search is a ‘diamond motion search’. 
         [0017]    The conventional diamond motion search is based on the premise that image portions within a video sequence will usually travel very short, or no distance from one frame to the next. As a result, the nearby locations surrounding a macroblock are searched first to see which yields a minimal distortion. From this it can be inferred which area is the most promising for further searching. Further searching is conducted in a similar manner, and so the diamond motion search gradually ‘zeroes in’ on a low distortion area. 
         [0018]    In particular, the locations above, below, to the left and to the right of a macroblock (in a ‘diamond shape’) are the first analysed. If the best location is the position below the original macroblock, then the next iteration of the search is conducted around that location and continues until a better match cannot be found—i.e. until it appears that the best motion vector for a macroblock has been located. 
         [0019]    Whilst the diamond motion search is efficient, it suffers from the drawback of being susceptible to local maxima. This is because initially unpromising search locations are further ignored (and so it can be said that the search is terminated prematurely before the best match in actuality has been found). Furthermore, the diamond motion search requires a check to be made following each iteration to determine the best candidate direction for further searching, which can be computationally demanding. In addition, it is a poor technique for video sequences containing rapidly moving objects for which macroblock translation may be large in comparison the effective search area. 
         [0020]    Another technique used to minimise the amount of information transmitted between frames is motion prediction. The information that this technique aims to minimise is that relating to motion vectors. It works on the assumption that a number of contiguous macroblocks within a frame are likely to have similar motion vectors. For example, in the above example in which there is a camera-pan across a stationary environment, the motion vectors of virtually all the macroblocks will be highly correlated. As a result, motion prediction takes into account the macroblocks for which motion vectors have already been calculated. Thus a ‘predicted motion vector’ can be used for subsequent macroblocks. To minimise bandwidth usage, the difference between the actual motion vector for that subsequent macroblock, and the predicted motion vector is transmitted. In particular, a ‘global motion vector’ may be set from which individual motion vectors deviate. 
         [0021]    Motion prediction may be used to seed macroblocks to be searched, and in the example of the diamond motion search, a preferred starting location for the diamond motion search may be decided as a result of the outcome of motion prediction for previous macroblocks. Whilst this approach generally yields an efficient outcome, this is not always the case. For example, motion prediction is not necessarily desirable in cases where the movement of adjacent macroblocks are not highly correlated—for example, where there are many image objects moving at in different directions. 
         [0022]    The development of technology in this area is focussed on providing more efficient algorithms that can determine a very good match for a macroblock whilst not necessarily needing to conduct an extensive search. This is so that a video stream encoder can perform encoding quickly and efficiently. However, this approach can cause detriment to the quality of a video stream in a number of cases in which there is quick and/or non-correlated movement of objects within a video sequence. This is not satisfactory within an operational environment in which broadcast quality is of great importance. 
         [0023]    In particular, when there is a motion search conducted, the number of steps taken to find the best match can vary significantly depending on the nature of the frames being encoded. This leads to non-determinism within such ‘efficient’ algorithms that is not necessarily suitable for encoding tasks demanding a guaranteed video quality, especially for applications such real-time high-definition television broadcasting. 
         [0024]    On the one-hand, conducting an exhaustive motion search can guarantee the best possible quality encoding (therefore making the best use of the channel bandwidth). However, the more comprehensive the motion search, the more computationally expensive it is, and so the longer encoding can take. This is a significant consideration when there are hard time limits imposed on encoding tasks, for example during real-time encoding. 
         [0025]    One solution to this problem is to provide hardware that is capable of conducting the computationally expensive calculations within the time constraints—for example, motion searching may be parallelised. However, such hardware comes at a cost of greater complexity and ‘silicon real-estate’ on a circuit board—and so a greater cost in financial terms as well. 
         [0026]    Therefore, there is a need for a method and system for motion search that provides an optimal trade-off between hardware costs, timing constraints, quality of video, and bandwidth limitations. 
       SUMMARY OF THE INVENTION 
       [0027]    According to a first aspect of the present invention there is provided a digital processing apparatus suitable for use in video encoding, the apparatus being arranged to conduct motion searching by comparing an image macroblock against a plurality of positions within an image search region, the apparatus comprising: 
         [0028]    a first 2D array comprising interconnected multi-directional shift registers for storing and shifting image values corresponding to a search window within the search region; 
         [0029]    a second 2D array comprising registers for storing image values corresponding to a macroblock; and 
         [0030]    a distortion calculation module operatively connected to the first and second 2D arrays, the distortion calculation module being arranged to calculate and output a distortion value corresponding to the difference between image values stored in associated registers of the first and second arrays, the distortion value thereby quantifying the correlation between the search window and the macroblock; 
         [0031]    wherein the apparatus is arranged, in use:
       to control the shift registers of the first 2D array to pass image values between adjacent shift registers to translate the position of the search window within the search region; and   to track distortion values outputted after progressive shifts of the first 2D array thereby determining an optimal registration position of the macroblock relative to the search region.       
 
         [0034]    Advantageously, by using interconnected multi-directional shift registers, it is possible to increase the speed with which a motion search comparison can be made between the macroblock and a search location. This is because a simple shift operation is computationally inexpensive. Although it may be more complicated to implement such multi-direction shift registers in hardware, they take up a relatively small area of silicon real-estate and provide substantial speed benefits over prior known hardware-implemented motion searching apparatus. 
         [0035]    Ideally, the interconnections between the multi-directional shift registers cross-link the shift registers to one another so as to enable image values to be passed between adjacent shift registers both horizontally and vertically. Ideally, the interconnections are bi-directional to enable image values to be passed in both directions along horizontal or vertical directions. Advantageously, the cross-linking and bi-directionality of the interconnections grants flexibility to the chosen motion search pattern of the macroblock relative to the search region. 
         [0036]    Preferably, the shift registers are arranged to pass values in a common direction per shift. Advantageously, this simplifies the operation of the shift registers, thereby allowing their control to be simplified. For example, a single shift command can control all of the shift registers to pass values between adjacent shift registers from left to right—thereby offsetting the position of the search window one position to the left within the search region. 
         [0037]    Preferably, the apparatus comprises a cache for storing image values corresponding to the search region. Ideally, the apparatus is arranged, in use, to transfer appropriate image values from the cache to shift registers disposed along the periphery of the first 2D array so as to reconstruct the search window following a shift operation. 
         [0038]    Advantageously, the combination of the cache and the first 2D shift array provides an optimal trade off between speed and architectural complexity and flexibility. It will be understood that during a shift operation, shift registers on a peripheral leading edge of the first 2D array will shift their values to adjacent shift registers located inward of the cache. Accordingly, the cache can be used to repopulate those shift registers with appropriate image values. For example, if the values in the shift registers are being shifted one place from left to right, the shift registers disposed on the leftmost leading peripheral edge of the first 2D array will transfer their pre-shift values to respective adjacent shift registers to the right. Accordingly, the post-shift values of those leftmost shift registers are obtained from the cache. 
         [0039]    Preferably, the apparatus is arranged, in use, to initially load image values into the first 2D array corresponding to a search window centrally located within the search region. Advantageously, centre-weighting the search increases the likelihood of finding an optimal match early. Preferably, the apparatus is arranged, in use, to control the shift registers of the first 2D array to progressively translate the position of the search window within the search region in a spiral search pattern. Advantageously, a spiral search pattern is centre-weighted and requires only a single shift per unique search location. Accordingly, the spiral search pattern represents a highly efficient way of searching a macroblock against a search region. 
         [0040]    Preferably, the apparatus comprises a motion vector generator for generating a motion vector corresponding to the relative positional difference between the macroblock and the search window. It will be appreciated that the calculation of motion vectors are well known to a person skilled in the art. 
         [0041]    Preferably, the apparatus comprises a bandwidth cost estimation module for estimating a bandwidth cost associated with a distortion value and a corresponding motion vector. Ideally, the bandwidth cost estimation module is arranged to track an optimal bandwidth cost associated with encoding a macroblock. 
         [0042]    Preferably, the apparatus comprises a time budget management module for controlling at least the number of shifts carried out by the first 2D array so as to manage the time spent performing each motion search operation. To this end, the time management module may be arranged to track the time taken to carry out one or more motion searches. Advantageously, the time management module can therefore ensure that a video encoding operation is time-deterministic. 
         [0043]    The time budget management module may be operatively connected to the distortion calculation module for monitoring the distortion value associated with each shift. Ideally, the time budget management module is arranged to early terminate a shift operation if the distortion value is below a threshold value. Similarly, the time budget management module may be operatively connected to the bandwidth cost estimation module to monitor an optimal bandwidth cost, the time budget management module being arranged to early terminate a shift operation if the bandwidth cost is below an associated threshold value. 
         [0044]    Preferably, the time budget management module is arranged to dynamically control one or more threshold values. 
         [0045]    Ideally, the time budget management module is arranged to receive a time budget within which to perform a plurality of motion search operations and dynamically apportion the time spent on each motion search operation in dependence on the progress of each motion search and/or the priority assigned to each motion search operation. 
         [0046]    Advantageously, it is possible to exploit the possibility of early termination to get more work out of the hardware than if an exhaustive search is conducted for each search region of the plurality. For example, if the time budget provides for N cycles, and an exhaustive search takes M cycles, then it is possible to do N/M searches. However, it is also possible to make use of early termination to conduct a greater number of searches using the same hardware. For example, if the average time of an early-terminated search is P cycles (where P&lt;M) then conducting N/P searches with the same hardware. 
         [0047]    The apparatus may comprise a seed list generator for generating a prioritised list of seed search regions against which a macroblock is to be searched. To this end, the seed list generator may be arranged to analyse a video image frame to estimate seed search regions within which to conduct more detailed motion searches in respect of a given macroblock. 
         [0048]    Accordingly, and more advantageously by ordering and weighting the list the higher priority (typically earlier) searches can be assigned more of the total seed list time-budget. The time budgeting will lead to a deterministic maximum time, but the outcome may be sub-optimal for one or more of the searches (i.e. they run out of time before finding the ‘best’ match). In the worst case the outcome could be severely sub-optimal—but this is unlikely. 
         [0049]    Preferably, the seed list generator is arranged to down-sample a video image frame and a macroblock, feed the down-sampled video image frame and macroblock into the first and second 2D arrays to conduct a motion search operation and thereby determine a prioritised list of seed search regions within the original image frame against which the original macroblock may be searched. 
         [0050]    Preferably, the time budget management module may be operatively connected to the seed list generator to receive a prioritised list of candidate search regions. 
         [0051]    Preferably, the apparatus is arranged to compare an image macroblock as well as its sub-partitions against a position within the image search region as part of a common comparison operation. Advantageously, the common comparison operation enables multiple encoding approaches to be determined substantially simultaneously. 
         [0052]    Preferably, the distortion calculation module is arranged to calculate and output, as part of a common operation, a plurality of distortion values, each distortion value corresponding to either a macroblock or one of the sub-partitions of the macroblock. Advantageously, it is therefore possible to quantify the correlation between a macroblock and a position within the search region and as part of the same operation also quantify the correlation between macroblock sub-partitions and their associated positions within the search region. 
         [0053]    Preferably, the distortion calculation module comprises a distortion value summing tree for progressively summing the differences between image values in the first and second 2D arrays. Preferably, the root of the summing tree is arranged to output the total sum of the differences between the first and second 2D arrays, thereby outputting the correlation between the macroblock and a position within the search region. Preferably, the summing tree comprises intermediate sampling points at each of which is output the correlation between macroblock sub-partitions and their associated positions within the search region. Advantageously, the summing tree represents a very efficient way to calculate both total and partial sums of the differences between the first and second 2D arrays. 
         [0054]    Preferably, the bandwidth cost estimation module comprises a cost-tracking table arranged to track optimal distortion values associated with the macroblock and each sub-partition. Preferably, the cost-tracking table is further arranged to track motion vectors associated with the optimal distortion values. Advantageously, it is possible to concurrently generate a set of bandwidth costs. Therefore, advantageously, the apparatus can be further arranged, in use, to select the most appropriate encoding solution in response to the set of bandwidth costs within the cost-tracking table. 
         [0055]    It should be appreciated that an encoding solution may comprise encoding a macroblock-sized distortion map together with a single motion vector (e.g. cost 16×16=bc of 16×16+1mv) or one of aggregated sub-divisions thereof (e.g: 
         [0000]      cost 16×8=( bc  of 16×8 a+ 1 mv )+( bc  of 16×8 b+ 1 mv ); or
 
         [0000]      cost 8×16=( bc  of 8×16 a+ 1 mv )+( bc  of 8×16 b+ 1 mv ); or
 
         [0000]      cost 8×8=( bc  of 8×8 a+ 1 mv )+( bc  of 8×8 b+ 1 mv )+( bc  of 8×8 c+ 1 mv )+( bc  of 8×8 d+ 1 mv ); or
 
         [0000]      cost 4×4=16 mv+bc  of 4×4( a . . . p );
 
         [0000]    etc.) 
         [0056]    According to a second aspect of the present invention there is provided a method of conducting motion searching for use in video encoding in which an image macroblock is compared against a plurality of positions within an image search region, the method comprising the steps of: 
         [0057]    loading image values corresponding to a search window within the search region into interconnected multi-directional shift registers of a first 2D array; 
         [0058]    loading image values corresponding to a macroblock into the registers of a second 2D array; 
         [0059]    calculating and outputting a distortion value corresponding to the difference between image values stored in associated registers of the first and second arrays, the distortion value thereby quantifying the correlation between the search window and the macroblock; 
         [0060]    controlling the shift registers of the first 2D array to pass image values between adjacent shift registers to translate the position of the search window within the search region; and 
         [0061]    tracking distortion values outputted after progressive shifts of the first 2D array to determine an optimal registration position of the macroblock relative to the search region. 
         [0062]    It will be understood that features of the first and second embodiments of the present invention may be combined or interchanged where context allows. Accordingly aspects of the present invention provide a method and an apparatus for conducting motion search for use in video encoding. Advantageously, the motion search can be time-deterministic. The motion search may be fully costed, adaptive and/or multi-portion. 
     
    
     DETAILED DESCRIPTION OF THE INVENTION 
       [0063]    Embodiments of the present invention will now be described by way of example. 
         [0064]    A general overview of embodiments of the present invention will first be described before explaining the detailed implementation in hardware at a module level. 
         [0065]    Overview 
         [0066]    As mentioned, it is necessary to find the best match for a macroblock within a reference area (an image search region). Generally, a standard target macroblock size is 16×16 pixels (or pels) and the image search region is generally 48×48 pixels. However, for ease of understanding,  FIG. 1  shows an illustrative example of 4×4 pixel block  10 , which is being compared against a 12×12 image search region  20 . It will be understood however, that the same principles apply to macroblocks  10  of 16×16 size and corresponding larger image search regions. 
         [0067]    In this illustrative example, for an exhaustive motion search, the block  10  will need to be compared with the underlying image of the search region in 9×9 (i.e. 81) different locations. 
         [0068]    Pixels of macroblocks and image search region may be of one of hundreds of different luminance levels. However, for simplicity, only four different luminance levels are represented in the present illustrative example. I.e. the block  10  and the search region  20  contain only four different luminance levels, as indicated in  FIG. 2  by the four styles of hatching. 
         [0069]    During an iteration of a search, the luminance of each block  10  is compared with the luminance of an aligned area within the search region  20 . This comparison is conducted using a method known in the art as ‘the sum of absolute differences (SAD)’. This method averages the difference in luminance levels of the sixteen pixels being compared, thereby outputting a single distortion value. It will be understood that other distortion methods and metrics are possible—for example, the sum of absolute transform differences (SAID) that conducts matches in the frequency domain. In particular, as is known in the art, SATD works by taking a frequency transform, usually a Hadamard transform, of the image values being compared. 
         [0070]      FIGS. 2 to 4  show the block  10  being compared against various locations within the same search region  20 . In particular,  FIG. 2  shows a comparison against a first top-right location,  FIG. 3  shows a comparison against a second bottom-middle location and  FIG. 4  shows a comparison against a third top-left location within the search region  20 . As can be seen, the match shown in  FIG. 2  will have the highest distortion value returned by the SAD metric (worst match),  FIG. 3  will be of an average distortion, and  FIG. 4  has no distortion (perfect match). In particular, the values in the 4×4 block  10  and the corresponding values in the top-left location within the search region  20  are identical. 
         [0071]    During a conventional diamond motion search, the 4×4 block will be first compared against the central location, and locations above, below, to the left and to the right of the centre. Each of the SAD results for each of these initial locations will be compared before subsequent match trials. In the example of a luminance arrangement shown in  FIGS. 2 ,  3  and  4 , the most promising SAD result found by the initial matching exercise would be at the second middle-bottom location, as shown in  FIG. 3 . As the diamond motion search is not exhaustive, areas of search that don&#39;t appear to initially yield good SAD results are not further investigated. Thus the top, left and right locations are ignored and the algorithm focuses on the area at the bottom. 
         [0072]    A second diamond search surrounding this bottom location would then be conducted and so forth. Therefore, the diamond motion search will be drawn into the local maxima presented by the middle-bottom location instead of resolving the better match at the top-left location as shown in  FIG. 4 . 
         [0073]    In contrast, the present invention is able to conduct comprehensive and deterministic searches that can always find the best match. 
         [0074]    The search pattern adopted by the present embodiment is spiral, starting from the centre of the search region  20 , and spiralling outwards clockwise. Referring to  FIG. 5 , if the top left hand pixel [*] of the centred 4×4 block  10  is treated as the reference pixel for that block  10 , the spiral pattern will proceed in the numerical order shown. Thus it can be seen that all 81 different locations will be searched in a fixed length search. 
         [0075]    This search pattern is particularly advantageous because it allows the exhaustive motion search to be implemented in way that can reduce the total number of hardware operations taking place to complete the exhaustive motion search very quickly. In particular, whilst algorithms such as the diamond motion search are set up to run a non-exhaustive search efficiently on general purpose processing architectures, the present embodiment takes a different approach in that an exhaustive search is carried out on dedicated hardware architecture. Advantageously, this task is handled in a computationally efficient manner, and the hardware used to carry out the task does not require as much ‘silicon real estate’ as a general-purpose architecture to do so. In other words, assuming that an exhaustive motion search is necessary, the present hardware arrangement allows that exhaustive motion search to be conducted more quickly than other prior known hardware arrangements. 
         [0076]    The hardware realisation of the spiral search is via a series of registers. More precisely, a 2D array of interconnected multi-directional shift registers is used to perform successive comparisons of the target block  10  against different areas within the image search region  20 . 
         [0077]    The principle of how this 2D shift array arrangement operates is shown schematically in  FIG. 6  in which a schematic view of an apparatus  1  for conducting motion searching is shown. In this illustrative example, the shift array  32  is a 4×4 array of shift registers, the shift array  32  being represented schematically in  FIG. 6  behind a standard 2D array  30  of standard registers also arranged in a 4×4 block. The 4×4 block to be compared is loaded into the standard array  30 . The centre part of the image search region  20  against which the block  10  is to be compared is loaded into the shift array  32 . 
         [0078]    For each comparison made, the difference between the pixel values held by the standard array  30  and the corresponding pixel values of the shift array  32  is calculated using a sum of absolute difference (SAD) approach. In particular, a distortion calculation module  50  operatively connected to shift array  32  and the standard array  30  is arranged to calculate a distortion value corresponding to the difference between image values stored in the standard array  30  and the shift array  32 . After the entire reference seed region has been searched, the best sum of absolute difference result in the form of the lowest distortion value is used to indicate the best match within the search region for the block  10  being searched. 
         [0079]    From this, the motion vector for the match position can be determined. In particular, a motion vector generator  60  tracks the position of the block  10  within the search region and whenever a distortion minima is encountered, generates a motion vector associated with that minima. The motion vector and the corresponding distortion value can be stored alongside one another in a cost-tracking table  55 . 
         [0080]    Viewed face-on, the shift array  32  is able to shift in either the horizontal or vertical direction. Therefore, to execute the first step of the spiral search, the shift array  32  shifts the values loaded into the registers down one place. The values in the bottom row are discarded, and a first cache  40  populates the values in the top row. To execute the second step, the shift array  32  shifts the values in its registers one place from right to left, the values in the left-most columns being discarded, the right-most columns being populated by a second cache  42 . The bottom and left-most rows are populated in a similar way by a third cache  44  and fourth cache  46 . It will be understood that these different cache entities  40 ,  42 ,  44 ,  46  are shown to be separate for ease of understanding. In an implementation of the present invention, a single cache in fact fulfils their separate functions. 
         [0081]    Advantageously, the shift array  32  obviates the need to load in a completely new set of pixel luminance values from a cache every time a comparison is to be made. Rather, the majority of the values are retained within the shift register, but merely shifted in position to make way for a row or column of new values. 
         [0082]    In one implementation of the present invention, the shift array  32  may be sufficiently large to preclude a cache hit for every single shift. In particular, the search window is smaller than the shift array  32  and so image values stored in the shift array  32  may cover the search region at least in part. Moreover, in a particularly advantageous implementation of the present invention the shift array  32  may be sized to accommodate either the entire width or height of the search region. Advantageously, by restricting the hits on the cache to row-only data maximises the efficiency of the transfer between the cache and the shift array  32 . 
         [0083]    However, referring back to the illustrative example in FIG.  6 —in which the cache transfers image rows and columns—the benefit of this arrangement is nonetheless clear. Rather than needing to load  16  new values (4×4) for each comparison to be made, only a row or column—i.e. 4 new values need be loaded from the cache. The 12 other values are already in the array—having been retained after the shift. 
         [0084]    This is useful as it can be computationally less expensive to shift  16  values+load  4  new values from cache, than load  16  new values from cache each time. Thus, by using the combination of a 2D shift array  32  and a supporting cache, an exhaustive motion search can be carried out very efficiently in terms of computational cost in hardware. 
         [0085]    This approach has further advantages over a conventional diamond motion search in that it does not suffer from delays associated with checking, after each iteration, which result indicates the best place to continue a search for a best match. That is, unlike a conventional diamond motion search, the continued search is not contingent on a computationally expensive comparison. Accordingly, it is possible to very quickly compare all of the possible locations within a search region to determine a best match without needing to conduct an intermediate check before moving onto the next iteration of the search. As a result, the process of the present embodiment can be pipelined, and is always guaranteed to find the best match within a given search extent by the end of a predetermined number of clock cycles. As such, the search is high quality and deterministic. 
         [0086]    As mentioned, the simplified examples shown in  FIGS. 1 to 6  show a 4×4 block being searched against a 12×12 reference seed region. However, the present embodiment finds particular application in the situation where a standard macroblock of size 16×16 is searched against an area of 48×48. It will be appreciated, under these conditions the advantages of this spiral searching technique is far more pronounced. 
         [0087]    The versatility of the spiral search can be exploited further in the determination of the best macroblock-motion vector combinations. 
         [0088]    As mentioned previously, when tracking macroblocks from one frame to the next within the same scene, there is a good chance that the motion vectors of large sets of macroblocks will be highly correlated. As a result, it may be appropriate to define a global motion vector to be applied to all the macroblocks within a frame. This provides a good starting point from which to determine the likely motion vector of each macroblock and thus also to define where the reference seed region to search within will be. However, if there is a dramatic event in a video sequence (for example, a scene change or movement by a number of different objects in different direction) then a global motion vector may not necessarily be appropriate, and it becomes necessary to be able to track individual macroblocks, and specify where the reference seed regions will be in another way. In particular, it can be advantageous to analyse the entire video frame to determine the best candidate macroblock-motion vector combinations. This can be accomplished using the same spiral search method and hardware architecture to conduct a coarse motion search. In particular, a seed list generator can be used to utilise the results of the coarse motion search to generate a prioritised list of seed search regions. 
         [0089]    In a large area search (coarse motion search) a high-resolution video frame image is down-sampled. Similarly, each macroblock is also down-sampled for use in searching the entirety of the high-resolution video frame. By way of example, a High-Definition (HD) video frame of resolution 1920×1080 may be down-sampled by a factor of eight to a ‘thumbnail’ 240×135 image, and a 16×16 macroblock is shrunk to a 2×2 mini-macroblock. The 2×2 mini-macroblock is then searched against the thumbnail image using the same spiral search as above. 
         [0090]    The spiral search can therefore be used in the same way to compare the downscaled macroblocks against the reference search region, which in this case is the downscaled frame. 
         [0091]    The purpose of this coarse level searching is more for determining a number of potential candidates for further investigation—i.e. by indicating roughly where within the frame a macroblock may have moved to. The further investigation is achieved by conducting subsequent more fine-grained searching operations in which a normal-sized macroblock of size 16×16 is searched within the standard search area—the reference seed region of size 48×48. Thus, the large area motion search provides an indication of where potential original motion vectors may be obtained for each macroblock. 
         [0092]    It will be understood that in the event of a complete scene change that there may not necessarily be any good mini-macroblock matches available. There may be instead a large and (as the search continues for each mini-macroblock) an increasing number of mediocre candidates. In this case, it is useful not to spend too long in trying to find a best match for each potential candidate in the more fine-grained operation following on from each coarse-grained match. 
         [0093]    As such, the method and system of the present embodiment comprises a time budget management module for controlling the time spent on one or more motion searches. The time budget management module may set an absolute time threshold, or a time budget threshold to limit the amount of time to be spent on attempting to resolve the best match out of a list of potential candidates. 
         [0094]    The absolute time threshold is used to specify the extent of each spiral search. For example, referring to  FIG. 5 , instead of permitting the spiral search to reach the extremities of the reference seed region (examining 81 search locations), the absolute time threshold can limit the number of iterations. For example, the limit may be set to 40 search locations—effectively halving the search extent and so time per macroblock search. 
         [0095]    The time budget threshold operates in a similar way, in that the extent of each spiral search is limited. However, the time devoted to each conducted search is weighted in order of priority. For example, where there are a number of candidates to investigate further following on from a coarse level search, a greater proportion of the time budget is devoted to investigate the better candidates from the results of the coarse level search. To this end, the time budget management module is arranged to be able to receive from an output of the coarse level search: a list of potential candidates to investigate further, their priority ranking and a total time budget in which to investigate the entire list. The management module will apportion the total time appropriately. 
         [0096]    Another advantage of the apparatus of the present invention derives from another phenomenon—referred to here as multi-partitioning—which is supported by encoding standards. 
         [0097]    As mentioned previously, macroblocks are usually 16×16 pixels in size. However, encoding standards support the fragmentation of this standard macroblock into subdivisions (such as two 8×16 blocks, two 16×8 blocks, four 8×8 blocks, eight 4×8 blocks, eight 8×4 blocks or sixteen 4×4 blocks). During a standard motion search, each of these fragments can be compared against the reference seed region independently of one another to find matches for each sub-partitions. Multi-partitioning in this way can therefore allow a better match between image portions of a series of frames to be determined. In particular, macroblock fragments may be better matched (and potentially in a less bandwidth-intensive way) than through comparing a 16×16 non-fragmented macroblock. Thus, the overall bandwidth cost of fragmentation may be less than non-fragmentation 
         [0098]    To expand on this point, the reusability of macroblock information from one frame to the next requires two main components associated with the original 16×16 macroblock to be determined—the motion vector translating the original macroblock to the new location in a subsequent frame, and the difference (‘delta’ Δ) between that translated macroblock and the new image. In short, the bandwidth cost is that to transmit/represent the motion vector my and the difference Δ (in terms of bit count bc). 
         [0099]    By way of example, bandwidth cost are represented below for a single 16×16 macroblock (a) four 8×8 macroblocks (b) and sixteen 4×4 macroblocks (c): 
         [0000]      cost=1 mv+bc (1×(16×16×Δ)  (a)
 
         [0000]      cost=4 mv+bc (4×(8×8×Δ)  (b)
 
         [0000]      cost=16 mv+bc (16×(4×4×Δ)  (c)
 
         [0100]    In the event that the single delta Δ in (a) is much higher than the individual deltas Δ in (b) or (c), then this can more than offset the three or fifteen additional motion vector costs in (b) and (c) respectively, making (b) or (c) the less bandwidth intensive option. 
         [0101]    In any case, as well as running comparisons for the 16×16 macroblocks, it is also very useful to find out whether there are good matches within the reference seed region for the fragments of the standard 16×16 macroblock as these may provide a better way of encoding the video sequence. 
         [0102]    The advantage of the spiral search method and system in this context is that for every iteration or shift, it is possible to simultaneously compare against the reference seed region every permutation of a fragmented macroblock, as well as the main macroblock itself. That is, for every iteration, as well as running a comparison against the reference seed region with a single target 16×16 macroblock, the present embodiment also and simultaneously compares the reference region against two 16×8 blocks, two 8×16 blocks, four 8×8 blocks, eight 8×4 blocks, eight 4×8 blocks and sixteen 4×4 blocks. In other words, 41 searches are conducted simultaneously for each iteration. 
         [0103]    To assess the best fragmentation pattern to use, the present embodiment comprises a fragment cost comparator for determining which macroblock arrangement has the lower bandwidth cost after the spiral search has completed. 
         [0104]    Overall, it can be seen that the present embodiment of the invention provides an improved motion estimation apparatus and method that is exhaustive, multi-partition (i.e. operating on different macroblock fragment combinations), fully-costed (i.e. the bandwidth cost of a number of different encoding approaches are measured and compared against one another), time-deterministic (i.e. the speed at which a motion search is conducted can be predetermined) and adaptive (time thresholds can be altered to be able to meet varying timing demands). 
         [0105]    Module Level Description 
         [0106]    A detailed description of the motion search apparatus at a module level will now be described which allows the implementation of the above principles of operation. 
         [0107]    In particular, the module level description explains the architecture, interfaces, memory/register maps, and behaviour of an integer Motion Estimation Processing Unit (MEPU) module. 
         [0108]    1. Overview 
         [0109]      FIG. 7  represents the general behaviour of the MEPU module. The module will be fed with a target macroblock comprising a 16×16 pel luminance array and a reference seed region comprising a 48×48 pel luminance representation. Up to 32 requests may be enqueued for processing in strict queue order. 
         [0110]    Having been fed with a target macroblock and a reference seed region, the engine will then perform an exhaustive integer-pel search across the 33×33 integer search extent, using a sum of absolute differences (SAD) cost metric to determine the optimum best-match location. The engine runs in two modes:
       8×8 mode—The outcome will be nine motion vectors, corresponding to the best match for each of the nine possible block partitions (i.e. 16×16, 2×(16×8), 2×(8×16) and 4×(8×8)). It will also return an aggregate cost metric for each of the four partition classes (i.e. 16×16, 16×8, 8×16 and 8×8). In this case the optimum (best-match) location is chosen as that location giving the lowest cost metric comprising the sum of the SAD and a motion-vector costing (see section 4.3.1.1).   4×4 mode—The outcome will be sixteen motion vectors, corresponding to the best match for each of the sixteen 4×4 sub-partitions. It also returns the SAD cost metric for each 4×4 partition. In this case the optimum (best-match) location is chosen as that location giving the lowest cost metric comprising the sum of the SAD and an alternate motion-vector costing (see section 4.3.2.1).       
 
         [0113]    The module expects the user to enqueue the macroblock and seed requests, which will be advanced into the ME engine. Each macroblock will be specified with a macroblock and wavefront identifier, and each seed will be specified with a seed reference picture identifier. The module will conduct the motion search (as illustrated in  FIG. 7 ), accumulating the best metrics over a sequence of seeds (the list) for a macroblock. Upon completion of a seed list (denoted by the final request being enqueued with a last marker) the result will be published to the output queue and the user will be alerted. 
         [0114]    The module may optionally be configured to ignore any locations visited during a search where the reference data for that location does not lie wholly within the reference picture. 
         [0115]    2. Architecture 
         [0116]      FIG. 8  illustrates the architecture of the MEPU core module.  FIG. 9  shows the integration of the MEPU core into the wider system. 
         [0117]    3. Interfaces 
         [0118]    3.1 Global Signals 
         [0000]    
       
         
               
               
               
             
           
               
                   
               
               
                 Signal 
                 Direction 
                 Description 
               
               
                   
               
             
             
               
                 RST 
                 I 
                 Asynchronous reset for all internal modules. 
               
               
                 CLK 
                 I 
                 Reference clock for all interfaces and internal modules. 
               
               
                   
               
             
          
         
       
     
         [0119]    3.2 ME Engine Control Bus 
         [0120]    The MEPU control bus conforms to the bus specification described in the ACE Internal Memory/Peripheral Bus Specification. It is comprised of the following signals: 
         [0000]    
       
         
               
               
               
               
             
           
               
                   
                   
               
               
                   
                 Signal 
                 Direction 
                 Description 
               
               
                   
                   
               
             
             
               
                   
                 mepuA [12:2] 
                 I 
                 Word address. 
               
               
                   
                 mepuBE [3:0] 
                 I 
                 Byte enables (per 8- 
               
               
                   
                   
                   
                 bit byte). 
               
               
                   
                 mepuR_W 
                 I 
                 Transfer direction. 
               
               
                   
                 mepuSEL 
                 I 
                 Target select. 
               
               
                   
                 mepuRDY [3:0] 
                 O 
                 Target ready. 
               
               
                   
                 mepuWD [31:0] 
                 I 
                 Write data. 
               
               
                   
                 mepuRD [31:0] 
                 O 
                 Read data. 
               
               
                   
                 mepuRDA 
                 O 
                 Read data available. 
               
               
                   
                   
               
             
          
         
       
     
         [0121]    The MEPU engine control bus connects to three internal targets. 
         [0122]    1. The MEPU engine request queue is mapped to mepuA[9:8]==01 (write only). 
         [0123]    2. The MEPU output result queue is mapped to mepuA[9]=0 (read only). 
         [0124]    3. The MEPU control &amp; status module is mapped to mepuA[9]==1 (read-write). 
         [0125]    3.3 Input Picture Cache Request Bus 
         [0126]    The input picture cache request bus comprises a set of signals which pass macroblock requests to the input picture cache sub-system. 
         [0000]    
       
         
               
               
               
             
           
               
                   
               
               
                 Signal 
                 Direction 
                 Description 
               
               
                   
               
             
             
               
                 ipCacheSEL 
                 O 
                 Input Picture Cache select. 
               
               
                 ipCacheRDY 
                 I 
                 Input Picture Cache Ready 
               
               
                 ipCacheWFI [1:0] 
                 O 
                 Input Picture Cache wavefront specifier 
               
               
                 ipCacheMBI [2:0] 
                 O 
                 Input Picture Cache macroblock specifier 
               
               
                   
               
             
          
         
       
     
         [0127]    The ipCacheRDY signal signals that the cache is ready to accept the request being offered by the SPPA sub-system. 
         [0128]    The ipCacheSEL signal signals that the input request queue has a valid seed request pending. 
         [0129]    3.4 Reference Picture Cache Request Bus 
         [0130]    The reference picture cache request bus comprises a set of signals which pass seed requests to the reference picture cache sub-system. 
         [0000]    
       
         
               
               
               
               
             
           
               
                   
                   
               
               
                   
                 Signal 
                 Direction 
                 Description 
               
               
                   
                   
               
             
             
               
                   
                 impreqSEL 
                 O 
                 Reference Picture Cache select. 
               
               
                   
                 impreqRDY 
                 I 
                 Reference Picture Cache Ready 
               
               
                   
                 impreqRID  
                 O 
                 Reference Picture Cache reference  
               
               
                   
                 [3:0] 
                   
                 picture identifier 
               
               
                   
                 impreqRX  
                 O 
                 Reference Picture Cache reference  
               
               
                   
                 [13:0] 
                   
                 picture seed coordinate 
               
               
                   
                 impreqRY  
                 O 
                 Reference Picture Cache reference  
               
               
                   
                 [13:0] 
                   
                 picture seed coordinate 
               
               
                   
                   
               
             
          
         
       
     
         [0131]    The impreqRDY signal signals that the cache is ready to accept the request being offered by the MPEU sub-system. 
         [0132]    The impreqSEL signal signals that the input request queue has a valid macroblock request pending. 
         [0133]    3.5 Input Picture Cache Data Bus 
         [0134]    The macroblock delivery data interface is comprised of the following signals: 
         [0000]    
       
         
               
               
               
             
           
               
                   
               
               
                 Signal 
                 Direction 
                 Description 
               
               
                   
               
             
             
               
                 mbSEL 
                 I 
                 MB staging buffer  
               
               
                   
                   
                 Target select. 
               
               
                 mbWD [63:0] 
                 I 
                 Write data. 
               
               
                   
               
             
          
         
       
     
         [0135]    3.6 Seed Staging Buffer Bus 
         [0136]    The seed staging buffer data interface is comprised of the following signals: 
         [0000]    
       
         
               
               
               
               
             
           
               
                   
                   
               
               
                   
                 Signal 
                 Direction 
                 Description 
               
               
                   
                   
               
             
             
               
                   
                 sbA [7:0] 
                 O 
                 Port 1 (cache-side) D64 address. 
               
               
                   
                 sbCS [2:0] 
                 O 
                 Port 1 (cache-side) block select 
               
               
                   
                 sbSEL 
                 O 
                 Port 1 (cache-side) select 
               
               
                   
                 sbTA [7:0] 
                 O 
                 Port 2 (mepu-side) D384 address. 
               
               
                   
                 sbTSEL 
                 O 
                 Port 2 (mepu-side) Target select. 
               
               
                   
                 sbTD [383:0] 
                 I 
                 Port 2 (mepti-side) Read data. 
               
               
                   
                   
               
             
          
         
       
     
         [0137]    3.7 Status Port 
         [0138]    The status port comprises a single level interrupt output denoting that the motion search result queue is not empty. 
         [0000]    
       
         
               
               
               
               
             
           
               
                   
                   
               
               
                   
                 Signal 
                 Direction 
                 Description 
               
               
                   
                   
               
             
             
               
                   
                 rrIRQ 
                 O 
                 ME result queue not  
               
               
                   
                   
                   
                 empty interrupt request 
               
               
                   
                   
               
             
          
         
       
     
         [0139]    3.8 Status Monitoring Port 
         [0140]    The status monitoring port conforms to the specification described in the ACE Status Monitoring Port Specification. It is comprised of the following signals: 
         [0000]    
       
         
               
               
               
               
             
           
               
                   
                   
               
               
                   
                 Signal 
                 Direction 
                 Description 
               
               
                   
                   
               
             
             
               
                   
                 smWA [3:0] 
                 I 
                 Selector write address. 
               
               
                   
                 smWE 
                 I 
                 Selector write enable. 
               
               
                   
                 smWD [5:0] 
                 I 
                 Selector write data. 
               
               
                   
                 smSTATUS [15:0] 
                 O 
                 Selected internal status. 
               
               
                   
                   
               
             
          
         
       
     
         [0141]    4. Functional Blocks 
         [0142]    4.1 MEPU Control &amp; Status 
         [0143]    4.1.1 Functional Description 
         [0144]    The MEPU control &amp; status module provides a set of control/status registers that allow an external controller attached to the control bus to perform the following functions:
       configure ME engine cost metrics   configure ME engine termination thresholds   monitor internal status       
 
         [0148]    It also provides a status monitoring port that allows a selected subset of the internal status signals to be monitored by hardware outside the ME engine core. 
         [0149]    4.1.2 Registers 
         [0150]    The MEPU engine control &amp; status module has 6 software-programmable registers. They are mapped into a 24 byte region as follows: 
         [0000]    
       
         
               
               
               
               
               
             
               
               
               
               
               
               
               
               
             
               
               
               
             
               
               
               
               
             
               
               
               
               
               
               
             
               
               
               
               
               
               
             
               
               
             
           
               
                   
               
               
                 Offset 
                 Byte 3 
                 Byte 2 
                 Byte 1 
                 Byte 0 
               
               
                   
               
             
             
               
                   
               
             
          
           
               
                 00 16   
                 ete 
                 ipa 
                 il 
                 unused 
                 minSearchPoints 
                 unused 
                 maxSearchPoints 
               
             
          
           
               
                 04 16   
                 unused 
                 1T 
               
             
          
           
               
                 08 16   
                 unused 
                 cmvShift 
                 cmvLambda 
               
             
          
           
               
                 0C 16   
                 lce 
                 unused 
                 L1Cap 
                 unused 
                 L0Cap 
               
             
          
           
               
                 10 16   
                 cse 
                 unused 
                 ySize 
                 unused 
                 xSize 
               
             
          
           
               
                 14 16   
                 sadStatus 
               
               
                   
               
             
          
         
       
     
         [0151]    All registers are 32-bit writable only (see section 5.2). Writes to unused bytes are ignored. Reading unused bytes will return the value 0. 
         [0152]    4.1.2.1 ete (Early Termination Enable) 
         [0153]    Early termination enable. A single bit value, this defaults to TRUE. 
         [0154]    4.1.2.2 ipa (Input Picture Analysis Enable) 
         [0155]    Input Picture Anaysis mode enable. If TRUE selects 4×4 partitions to be searched and costed. If FALSE selects 8×8 partitions to be searched and costed. A single bit value, this defaults to FALSE. 
         [0156]    4.1.2.3 il (Interlaced 16×8 Partition Enable) 
         [0157]    Interlaced 16×8 partition enable. If TRUE, 16×8 partitions will be derived by splitting the target macroblock into even and odd rows. If FALSE, 16×8 partitions will be derived by splitting the target macroblock into upper and lower halves. A single bit value, this defaults to FALSE. 
         [0158]    4.1.2.4 minSearchPoints 
         [0159]    The search algorithm performs early termination during the search spiral. This parameter defines the earliest possible threshold at which termination may take place. This 10-bit parameter defaults to 144. 
         [0160]    4.1.2.5 maxSearchPoints 
         [0161]    The search algorithm is an exhaustive spiral search which spirals out from the nominal (0,0) coordinate—which corresponds to the (23,23) coordinate of the seed buffer, assuming that the (0,0) coordinate is the top left hand corner of the square 48×48 seed buffer. 
         [0162]    This 10-bit parameter defaults to 1023 i.e. Maximum physical search capacity of the hardware. 
         [0163]    4.1.2.6 rr (Result Ready) 
         [0000]    
       
         
               
               
               
               
               
             
           
               
                   
               
               
                 Bits 
                 Field Name 
                 Access 
                 Reset Value 
                 Notes 
               
               
                   
               
             
             
               
                 1:0 
                 Result ready 
                 rw 
                 00 2   
                 Control bit pair-  
               
               
                   
                   
                   
                   
                 see section 5.1. 
               
               
                   
               
             
          
         
       
     
         [0164]    The result pair indicates that the set of partition results is ready. The associated control bit may have one of the following values: 
         [0165]    0 indicates the result is available 
         [0166]    1 indicates the result is not available 
         [0167]    A signal indicating that the result is available means that the set of cost metrics and motion vectors have been accumulated over the list and published to the output queue. 
         [0168]    4.1.2.7 cmvLambda and cmvShift 
         [0169]    Lambda is a fixed point value used to pre-scale the cmv (cost of motion vector) expression. The scaling of the cmv expression will be pre-scaled by cmvLambda (16-bit) and post-scaled by cmvShift (8-bit). See Section 4.3.1 for more details. 
         [0170]    4.1.2.8 lce (List Cap Enable) 
         [0171]    List cap enable. A single bit value, this defaults to FALSE. 
         [0172]    The expected use of the module is to process two seed lists for a given macroblock (i.e. L0 and L1). These L0 and L1 lists generally correspond to forward and backward (in time) search lists, from which seeds are drawn in priority order. 
         [0173]    The design is intended to implement a budgeted clock cycle cap on the processing of each list. The algorithm implements a ‘fair’ allocation of clock cycles to the processing of each seed within a list, according to the following pseudo-code: 
         [0000]    
       
         
               
             
               
               
               
             
               
               
             
               
             
               
               
               
             
               
               
             
               
             
           
               
                   
               
             
             
               
                 if (list==0 &amp; seed==0) { L0Residue = L0cap; } 
               
               
                 else if(list==0 &amp; seed!=0) { L0Residue = (L0Residue-earlyTerminationUsage); } 
               
               
                 L0Allowance = L0Residue&gt;&gt;1; 
               
               
                 if (list==1 &amp; seed==0) { L1Residue = L1cap + (L0Residue-PointTerminate); } 
               
               
                 else if(list==1 &amp; seed!=0) { L1Residue = (L1Residue-PointTerminate); } 
               
               
                 L1Allowance = L1Residue&gt;&gt;1; 
               
               
                 if (list==0) { 
               
             
          
           
               
                   
                 MaxSearchPoints &lt; L0Allowance ? 
                 UsableSearchPoints=MaxSearchPoints : 
               
             
          
           
               
                   
                 UsableSearchPoints=L0Allowance; 
               
             
          
           
               
                 } 
               
               
                 if (list==1) { 
               
             
          
           
               
                   
                 MaxSearchPoints &lt; L1Allowance ? 
                 UsableSearchPoints=MaxSearchPoints : 
               
             
          
           
               
                   
                 UsableSearchPoints=L1Allowance; 
               
             
          
           
               
                 } 
               
               
                   
               
               
                 NOTE: 
               
               
                 It is expected that zero or more L1 requests will immediately follow the L0 request list. 
               
             
          
         
       
     
         [0174]    4.1.2.9 L0Cap 
         [0175]    The search algorithm performs early termination during the search spiral. This parameter defines the maximum clock budget for processing the L0 list. This 12-bit parameter defaults to 1800. 
         [0176]    4.1.2.10 L1Cap 
         [0177]    The search algorithm performs early termination during the search spiral. This parameter defines the nominal clock budget for processing the L1 list. This 12-bit parameter defaults to 600. 
         [0178]    4.1.2.11 cse (Constrained Search Enable) 
         [0179]    Constrained search enable. A single bit value, this defaults to FALSE. If FALSE, all locations in a search are considered valid. If TRUE, only locations for which the reference data lies wholely within the reference picture are considered valid. 
         [0180]    4.1.2.12 xSize 
         [0181]    This 7 bit parameter defines the width of the reference picture (in macroblocks). This value is used in a constrained search to determine whether the current search location is valid. 
         [0182]    4.1.2.13 ySize 
         [0183]    This 7 bit parameter defines the height of the reference picture (in macroblocks). This value is used in a constrained search to determine whether the current search location is valid. 
         [0184]    4.1.2.14 mepuStatus 
         [0000]    
       
         
               
               
               
               
               
             
           
               
                   
               
               
                 Bits 
                 Field Name 
                 Access 
                 Reset Value 
                 Notes 
               
               
                   
               
             
             
               
                  0 
                 rprqWtStall 
                 r 
                 0 
                   
               
               
                  1 
                 rprqFull 
                 r 
                 0 
                   
               
               
                  2 
                 rprqNotEmpty 
                 r 
                 0 
                   
               
               
                  3 
                 iprqWtStall 
                 r 
                 0 
                   
               
               
                  4 
                 iprqFull 
                 r 
                 0 
                   
               
               
                  5 
                 iprqNotEmpty 
                 r 
                 0 
                   
               
               
                  6 
                 mepuResultQueueFull 
                 r 
                 0 
                   
               
               
                  7 
                 mepuBusy 
                 r 
                 0 
                   
               
               
                  8 
                 dmaBusy 
                 r 
                 0 
                   
               
               
                 31:9 
                 — 
                 r 
                 0 
                 Hardwired. 
               
               
                   
               
             
          
         
       
     
         [0185]    The dmaBusy field indicates that the unit dma is currently active fetching the next queued request item (e.g. Macroblock or seed buffer). The following values may be returned when this field is read: 
         [0186]    0 passive 
         [0187]    1 active 
         [0188]    The mepuBusy field indicates whether the ME engine PU is active. The following values may be returned when this field is read: 
         [0189]    0 passive 
         [0190]    1 active 
         [0191]    The rprqWtStall field indicates whether a write transaction to the reference picture seed request queue is stalled because the queue is full. The following values may be returned when this field is read: 
         [0192]    0 indicates an inbound queue write transaction is not currently stalled. 
         [0193]    1 indicates an inbound queue write transaction is currently stalled. 
         [0194]    The rprqNotEmpty field indicates whether the input reference picture seed request queue is empty. The following values may be returned when this field is read: 
         [0195]    0 indicates an inbound request queue is empty. 
         [0196]    1 indicates an inbound request queue is not empty. 
         [0197]    The rprqFull field indicates whether a reference picture seed request may be enqueued. The following values may be returned when this field is read: 
         [0198]    0 indicates an inbound request queue is not full. 
         [0199]    1 indicates an inbound request queue is full. 
         [0200]    The iprqWtStall field indicates whether a write transaction to the input picture macroblock request queue is stalled because the queue is full. The following values may be returned when this field is read: 
         [0201]    0 indicates an inbound queue write transaction is not currently stalled. 
         [0202]    1 indicates an inbound queue write transaction is currently stalled. 
         [0203]    The iprqNotEmpty field indicates whether the input picture macroblock request queue is empty. The following values may be returned when this field is read: 
         [0204]    0 indicates an inbound request queue is empty. 
         [0205]    1 indicates an inbound request queue is not empty. 
         [0206]    The iprqFull field indicates whether an input picture macroblock request may be enqueued. The following values may be returned when this field is read: 
         [0207]    0 indicates an inbound request queue is not full. 
         [0208]    1 indicates an inbound request queue is full. 
         [0209]    4.1.3 Status Monitoring 
         [0210]    The MEPU control &amp; status module has 16 hardware-programmable status select registers. They are located in the status select port register space as follows: 
         [0000]    
       
         
               
               
               
             
           
               
                   
                   
               
               
                   
                 Address 
                 Register Name 
               
               
                   
                   
               
             
             
               
                   
                  0 
                 StatusSelect00 
               
               
                   
                  1 
                 StatusSelect01 
               
               
                   
                  2 
                 StatusSelect02 
               
               
                   
                  3 
                 StatusSelect03 
               
               
                   
                  4 
                 StatusSelect04 
               
               
                   
                  5 
                 StatusSelect05 
               
               
                   
                  6 
                 StatusSelect06 
               
               
                   
                  7 
                 StatusSelect07 
               
               
                   
                  8 
                 StatusSelect08 
               
               
                   
                  9 
                 StatusSelect09 
               
               
                   
                 10 
                 StatusSelect10 
               
               
                   
                 11 
                 StatusSelect11 
               
               
                   
                 12 
                 StatusSelect12 
               
               
                   
                 13 
                 StatusSelect13 
               
               
                   
                 14 
                 StatusSelect14 
               
               
                   
                 15 
                 StatusSelect15 
               
               
                   
                   
               
             
          
         
       
     
         [0211]    Each of the StatusSelect00 . . . StatusSelect15 registers controls which internal status signal is output on the correspondingly numbered bit of the smSTATUS signal. Each register has the same layout, as follows: 
         [0000]    
       
         
               
               
               
               
               
             
           
               
                   
               
               
                 Bits 
                 Field Name 
                 Access 
                 Reset Value 
                 Notes 
               
               
                   
               
             
             
               
                 5:0 
                 StatusSelect 
                 w 
                 0 
                   
               
               
                   
               
             
          
         
       
     
         [0212]    The StatusSelect field determines which internal status bit drives the associated bit of the smSTATUS signal. If set to a value less than 32, the bit indexed by that value in the mepuStatus register is selected. If set to any other value, the selection is undefined. 
         [0213]    4.2 Request Queue 
         [0214]    Macroblock partition specifications for 8×8 partitions are: 
         [0000]    
       
         
               
             
               
               
               
               
               
               
               
             
           
               
                   
               
               
                 Drawing 1: macroblock partitions 
               
               
                   
               
             
             
               
                   
               
             
          
           
               
                   
                 8×8_a 
                 8×8_b 
                 8×16_a 
                 8×16_b 
                 16×8_a 
                 16×16 
               
               
                   
                 8×8_c 
                 8×8_d 
                   
                   
                 16×8_b 
               
               
                   
                   
               
             
          
         
       
     
         [0215]    Macroblock partition specifications for 4×4 partitions are: 
         [0000]    
       
         
               
             
               
               
               
               
               
             
           
               
                   
               
               
                 Drawing 2: macroblock partitions 
               
               
                   
               
             
             
               
                   
               
             
          
           
               
                   
                  0 
                  1 
                  2 
                  3 
               
               
                   
                  4 
                  5 
                  6 
                  7 
               
               
                   
                  8 
                  9 
                 10 
                 11 
               
               
                   
                 12 
                 13 
                 14 
                 15 
               
               
                   
                   
               
             
          
         
       
     
         [0216]    4.2.1 Registers 
         [0217]    The MEPU inbound request queue comprises 4 software-programmable registers. They are mapped into a 16 byte region as follows: 
         [0000]    
       
         
               
               
               
               
               
             
               
               
             
               
               
               
               
               
               
               
               
               
             
               
               
             
               
               
               
               
               
             
           
               
                   
               
               
                 Offset 
                 Byte 3 
                 Byte 2 
                 Byte 1 
                 Byte 0 
               
               
                   
               
             
             
               
                   
               
             
          
           
               
                 00 16   
                 imv 
               
             
          
           
               
                 04 16   
                 unused 
                 WF 
                 unused 
                 MBI 
                 unused 
                 list 
                 unused 
                 last 
               
             
          
           
               
                 08 16   
                 pmv 
               
             
          
           
               
                 0C 16   
                 unused 
                 MBY 
                 unused 
                 MBX 
               
               
                   
               
             
          
         
       
     
         [0218]    The registers are 32-bit writable only (see section 5.2). Any write to offset 00 16  will cause the entire entry to be advanced into the request queue. 
         [0219]    The imv (initial motion vector) is a 32-bit field packed according to the standard definition i.e. 
         [0220]    31:28 Reference picture identifier 
         [0221]    27:14 Motion vector x 
         [0222]    13:00 Motion vector y 
         [0223]    The last field is a single bit marker which identifies the request to be the last request for a given search list. When this information advances to the MEPU it will cause the aggregate cost and motion vector metrics to be published to the output queue. 
         [0224]    The list field is a single bit marker which indicates if the request belongs to list 0 (0) or list 1 (1). 
         [0225]    The WF (2-bits) and MBI (3-bits) are parameters which define the macroblock address in the input picture cache. This information will be passed directly to the input picture cache. 
         [0226]    The pmv is a 32-bit field packed according to the standard definition i.e. 
         [0227]    27:14 Predicted motion vector x 
         [0228]    13:00 Predicted motion vector y 
         [0229]    See section 4.5.1 for more detail on how the actual and predicted motion vectors are used in the calculation of the best-match cost metrics. 
         [0230]    The MBX and MBY are 6-bit parameters which define the macroblock address (in units of macroblocks). 
         [0231]    This is used in conjunction with the initial motion vector to define the address of the macroblock in a given reference picture. 
         [0232]    4.2.1.1 Calculation of Reference Picture Cache Address 
         [0233]    The reference picture cache address is calculated with respect to  FIG. 10 . 
         [0234]    4.3 Outbound Result Buffer 
         [0235]    The output (result) is 32-bit accessible register file that accesses the head of the result queue, which can be accessed as internal target 2 on the MEPU control bus interface. Reading the entry at address 2C 16  causes the entire entry to be removed from the queue. 
         [0236]    The queue entries have two formats, depending upon the operating mode. 
         [0237]    1. The engine is operating upon 8×8 partitions (ipa=FALSE—see section 4.1.2.2) 
         [0238]    2. The engine is operating upon 4×4 partitions (ipa=TRUE—see section 4.1.2.2) 
         [0239]    4.3.18×8 Mode Results 
         [0000]    
       
         
               
               
               
             
               
               
               
               
               
               
             
               
               
               
               
             
               
               
               
             
           
               
                   
                   
               
               
                   
                   
                 Name 
               
             
          
           
               
                   
                 Address [6:2] 
                 byte3 
                 byte2 
                 byte1 
                 byte0 
               
               
                   
                   
               
             
          
           
               
                   
                 00 16   
                 cost16×8 
                 cost16×16 
               
               
                   
                 04 16   
                  cost8×8 
                  cost8×16 
               
             
          
           
               
                   
                 08 16   
                 Zero fill 
               
               
                   
                 0C 16   
                 mv16×16 
               
               
                   
                 10 16   
                 mv16×S_a 
               
               
                   
                 14 16   
                 mv16×S_b 
               
               
                   
                 18 16   
                  mv8×16_a 
               
               
                   
                 1C 16   
                  mv8×16_b 
               
               
                   
                 20 16   
                  mv8×8_a 
               
               
                   
                 24 16   
                  mv8×8_b 
               
               
                   
                 28 16   
                  mv8×8_c 
               
               
                   
                 2C 16   
                  mv8×8_d 
               
               
                   
                   
               
             
          
         
       
     
         [0240]    The my (motion vector) is a 32-bit field packed according to the standard definition i.e. 
         [0241]    31:28 Reference picture identifier 
         [0242]    27:14 Motion vector x 
         [0243]    13:00 Motion vector y 
         [0244]    The reference picture identifier is carried forward from the input request, and comprises the reference picture identifier associated with the best-match motion vector. There is one resolved motion vector for each best-match per partition. 
         [0245]    The cost metrics are the aggregate costs for each partition class i.e. 
         [0000]    
       
         
           
             
               
                 
                   
                     cost 
                      
                     
                         
                     
                      
                     16 
                     × 
                     16 
                   
                   = 
                     
                    
                   
                     
                       Csad 
                       
                         16 
                         × 
                         1 
                          
                         ɛ 
                       
                     
                     + 
                     
                       Cmv 
                       
                         16 
                         × 
                         16 
                       
                     
                   
                 
               
             
             
               
                 
                   
                     cost 
                      
                     
                         
                     
                      
                     16 
                     × 
                     8 
                   
                   = 
                     
                    
                   
                     
                       Csad 
                       
                         16 
                         × 
                         3 
                          
                         A 
                       
                     
                     + 
                     
                       Cmv 
                       
                         16 
                         × 
                         4 
                          
                         A 
                       
                     
                     - 
                   
                 
               
             
             
               
                 
                     
                    
                   
                     
                       Csad 
                       
                         16 
                         × 
                         1 
                          
                         b 
                       
                     
                     + 
                     
                       Cmv 
                       
                         16 
                         × 
                         1 
                          
                         b 
                       
                     
                   
                 
               
             
             
               
                 
                   
                     cost 
                      
                     
                         
                     
                      
                     16 
                     × 
                     8 
                   
                   = 
                     
                    
                   
                     
                       Csad 
                       
                         3 
                         × 
                         16 
                          
                         A 
                       
                     
                     + 
                     
                       Cmv 
                       
                         8 
                         × 
                         16 
                          
                         a 
                       
                     
                     - 
                   
                 
               
             
             
               
                 
                     
                    
                   
                     
                       Csad 
                       
                         8 
                         × 
                         18 
                          
                         b 
                       
                     
                     + 
                     
                       Cmv 
                       
                         3 
                         × 
                         16 
                          
                         b 
                       
                     
                   
                 
               
             
             
               
                 
                   
                     cost 
                      
                     
                         
                     
                      
                     8 
                     × 
                     8 
                   
                   = 
                     
                    
                   
                     
                       Csad 
                       
                         8 
                         × 
                         8 
                          
                         a 
                       
                     
                     + 
                     
                       Cmv 
                       
                         8 
                         × 
                         8 
                          
                         a 
                       
                     
                     + 
                   
                 
               
             
             
               
                 
                     
                    
                   
                     
                       Csad 
                       
                         8 
                         × 
                         8 
                          
                         b 
                       
                     
                     + 
                     
                       Cmv 
                       
                         8 
                         × 
                         8 
                          
                         b 
                       
                     
                     + 
                   
                 
               
             
             
               
                 
                     
                    
                   
                     
                       Csad 
                       
                         8 
                         × 
                         8 
                          
                         c 
                       
                     
                     - 
                     
                       Cmv 
                       
                         8 
                         × 
                         8 
                          
                         c 
                       
                     
                     + 
                   
                 
               
             
             
               
                 
                     
                    
                   
                     
                       Csad 
                       
                         8 
                         × 
                         8 
                          
                         d 
                       
                     
                     + 
                     
                       Cmv 
                       
                         8 
                         × 
                         8 
                          
                         d 
                       
                     
                   
                 
               
             
           
         
       
     
         [0246]    4.3.1.18×8 Cost Metric: Informative 
         [0247]    The cost of motion vector metric (Cmv) for a given actual motion vector (amvy, amvx) is defined as: 
         [0000]        cmv =λ*( mv BitCost(( amvy +delta mvy )− pmvy )+ mv BitCost(( amvx +delta mvx )− pmvx ))
 
         [0248]    where
       (pmvy, pmvx) is the predicted motion vector for the macroblock   λ is a user defined encoding parameter.   (deltamvy,deltamvx) is the motion offset for the current search location (i.e. the offset within the spiral search region).       
 
         [0252]    Note: The predicted motion vector and the actual motion vector are enqueued with the request and the lambda parameter is a CSR block setting. 
         [0253]    The function mvBitCost( ) in the above equation is defined as: 
         [0000]        mv BitCost( d )=1+2*(Count LZ (0)−Count LZ (| d |))
 
         [0254]    and hence 
         [0000]        cmv= 2λ*(1+2*Count LZ (0)−Count LZ (| mvy−pmvy |)−Count LZ (| mvx−pmvx |))
 
         [0255]    Note that CountLZ(0) is an implementation defined constant value. In each case the best metric is recorded at the current search position if (and only if) the current (Csad+Cmv) is less than the stored (Csad+Cmv). 
         [0256]    The final implementation comprises a post-scaling step defined as: 
         [0000]        cmv =(2λ*(1+2*Count LZ (0)−Count LZ (| mvy−pmvy |)−Count LZ (| mvx−pmvx |))+LAMBDA_ROUND)&gt;&gt;LAMBDA_SHIFT
 
         [0000]    LAMBDA_SHIFT=cmvshift
 
LAMBDA_ROUND=cmvshift&gt;0?1&lt;&lt;(cmvshift−1):0
 
         [0257]    The variable cmvShift is defined in Section 4.1.2.6. 
         [0258]    4.3.2 4×4 Mode Results 
         [0259]    In order to optimise the re-use of the hardware resources, the 4×4 mode results are split across two queue entries. The results for partitions 0-7 are contained in the first queue entry, whilst the results for partitions 8-15 are contained in the second queue entry. As before, an entire queue entry is removed when the field at address 2C16 is read. 
         [0000]    
       
         
               
               
               
             
               
               
               
               
               
               
             
               
               
               
               
             
               
               
               
             
           
               
                   
                   
               
               
                   
                   
                 Name 
               
             
          
           
               
                   
                 Address [6:2] 
                 byte3 
                 byte2 
                 byte1 
                 byte0 
               
               
                   
                   
               
             
          
           
               
                   
                 00 16   
                 sad1/9  
                 sad0/8  
               
               
                   
                 04 16   
                 sad3/11 
                 sad2/10 
               
               
                   
                 08 16   
                 sad5/13 
                 sad4/12 
               
               
                   
                 0C 16   
                 sad7/15 
                 sad6/14 
               
             
          
           
               
                   
                 10 16   
                 mv0/8  
               
               
                   
                 14 16   
                 mv1/9  
               
               
                   
                 18 16   
                 mv2/10 
               
               
                   
                 1C 16   
                 mv3/11 
               
               
                   
                 20 16   
                 mv4/12 
               
               
                   
                 24 16   
                 mv5/13 
               
               
                   
                 28 16   
                 mv6/14 
               
               
                   
                 2C 16   
                 mv7/15 
               
               
                   
                   
               
             
          
         
       
     
         [0260]    The my (motion vector) is a 32-bit field packed according to the standard definition i.e. 
         [0261]    31:28 Reference picture identifier 
         [0262]    27:14 Motion vector x 
         [0263]    13:00 Motion vector y 
         [0264]    The reference picture identifier is carried forward from the input request, and comprises the reference picture identifier associated with the best-match motion vector. There is one resolved motion vector for each best-match per partition. 
         [0265]    The sad metrics are the outcome of a simple sum-of-absolute differences for the partition. 
         [0266]    The decision for the best match for the nth 4×4 partition is made on the basis of the lowest cost4×4_n metric, defined as: 
         [0000]      cost4×4 —   n=Csad   4×4     —     n   +Cmv   4×4  
 
         [0267]    4.3.2.14×4 Cost Metric: Informative 
         [0268]    The motion vector cost metric (Cmv4×4) used in the expression above is defined as: 
         [0000]        Cmv   4×4 =(12*( abs (delta mvx )− abs (delta mvy ))−5 *abs ( abs (delta mvx−abs (delta mvy ))+1)&gt;&gt;1
 
         [0269]    where (deltamvy,deltamvx) is the motion offset for the current search location (i.e. the offset within the spiral search region). 
         [0270]    Note that this cost expression is the same for each 4×4 partition. 
         [0271]    5. General Notes 
         [0272]    5.1 Control Bit Pairs 
         [0273]    In a number of the control registers, single bit control values are presented as bit pairs in the register. The results of writing to a bit pair are as follows: 
         [0274]    00 2  has no effect. 
         [0275]    01 2  sets the associated control bit to 1. 
         [0276]    10 2  sets the associated control bit to 0. 
         [0277]    11 2  has no effect. 
         [0278]    When a bit pair is read, the returned value is 01 2  if the associated control bit is set to 1 and 00 2  if the associated control bit is set to 0. 
         [0279]    The reason for implementing control bits as bit pairs is that it allows a subset of the control bits in a given register to be modified using a single write operation, rather than using a read-modify-write operation. 
         [0280]    5.2 32-bit Writable Registers 
         [0281]    Certain registers are described as being 32-bit writable. A 32-bit writable register can only be written by simultaneously writing to all bytes of the 32-bit word in which the register is located. If the register occupies all bytes of the 32-bit word (i.e. is 32 bits in size), this means the register can only be written as a whole. If the register only occupies some bytes of the 32-bit word (i.e. is less than 32 bits in size), this means that any other registers located in the same 32-bit word must also be written when the register is written. 
         [0282]    Writes to a 32-bit word containing a 32-bit writable register are ignored if not all bytes are enabled to be written.