Why is the above architecture chosen for XCode-II? In moving from video processing algorithms to a final IC implementation has to consider two critical factors:

· Complexity
· Cost
Complexity is best solved by an architecture that emphasizes programmability, while Cost is best handled by more fixed logic (or vector processor type units). In the XCode-II video processor family, the logic and arithmetic operations required approach 40,000,000,000 arithmetic and logical operations per second -to make the entire solution programmable will result in many parallel execution units, but this will increase the cost (area) of the IC. To solve this using entirely fixed logic or vector processor units will make the challenge of implementing all the algorithmic complexity dangerous, as fixed logic transistors cannot be changed. If a higher level algorithmic improvement is discovered, a programmable architecture can implement this improvement, but a fixed logic one cannot.

Yet a fully programmable solution is a costly one that results in bigger ICs that may not be marketable or even incapable of achieving the required performance level to perform the task. Striking the balance is the major task to solve when using applying this architecture to solve high complexity high performance tasks such as video encoding.

The XCode is one solution or architecture that has struck this fine balance of managing the complexity and still delivering a cost effective package.

On XCODE-II technology

ViXS offered XCODE-II to address the following needs :

· Raise bar on quality of MPEG2 encoding by pushing the limits of the technology.
· Accelerated high quality transcoding and transrating with resolution changes.

When dealing with the algorithmic side, these are some of the tools implemented in XCODE family that is not normally seen in most encoder ICs.

MPEG Rate Control and bit allocation

In any sequence of moving pictures, one challenge is the budget to allocate bits on an inter-frame (frame to frame) and intra-frame (regions of a frame).

The Inter-Frame allocation problem has to follow rules on relative sizes of each compressed picture and the total sizes of a sequence of pictures must match the requested bitrate of the stream. One useful tool is how to deal with Scene Change. A scene change is a picture that is judged to be totally different from the previous one that motion estimation will not encode such a picture efficiently. This picture is now best encoded with intra-macroblocks, or as an I picture (if required). In the Fig 7 below, picture N+1 is judged to be a scene change. What this means is that picture N+1 will be encoded as mostly intra macroblocks without motion vectors. More bits should be allocated to picture N+1, but, to maintain the requested bitrate, the allocated bits to picture N (or even picture N-1) should decrease to avoid breaking the buffer rules and to allow the scene change to be compressed with less obvious artifacts.

The Intra-Frame bit allocation is further refinement of this idea. Once the budget of bits for a particular picture has been allocated, within that picture, the problem of intra-frame bit allocation is one that is able to determine the complexity of each region of the scene.

There are various methods to do this, and this paper will not reveal the details here, but all involve some preprocessing of the pictures and in more advanced cases, even takes into account the motion compensation involved. This level of preprocessing shares some similar ideas to a dual pass approach, where the intermediate results of the first past of
compression can be used to re-encode the picture sequence again, but the fundamental problem remains : how does one allocate bits on a regional basis in each picture? Some image processing techniques are useful here as the pixels that make up each region in each picture are what is visible, hence such a measure of region complexity has to be done using a complexity measure of each region, or in this case, each macroblock.

The Motion Search Not all motion search is the same. When a codec claims +/- 2048 motion search range, that only means that it is capable of generating motion vectors in that range, but in fact, a large motion vector is not necessarily the best way to encode a picture, often a smaller motion vector that is only marginally less exact of a match can result in a smaller bitstream for that macroblock. In fact, large motion vector search range is not meaningful in determining a good encoder as a good motion search implementation will expand search ranges only when needed and not work blindly to always search through a large range. Large motion vectors takes more bits to encode than small motion vectors.

上一页  [1] [2] [3] [4] [5] [6] [7] [8] 下一页