Most multimedia devices today have to support multiple codec standards. Take video codecs for example, a portable multimedia player usually supports the playback of the MPEG-1/2, MPEG-4 SP, WMV, and H.264/MPEG-4 Part 10 video contents. In order to reduce system cost, a single-chip SoC solution that supports all these standards is a sensible approach. From IC designers’ point of view this is not a serious problem since most (if not all) popular video codecs share the same block-based motion compensated transform coding data flow. In addition, many coding tools have similar architecture. However, there are some application issues that makes traditional codec design approaches unsatisfactory [1].
A major problem with existing approach of defining a codec standard is the lack of flexibility when new applications emerge. A video codec is composed of several coding tools (e.g. DCT/IDCT, MC, VLC/VLD, etc.). However, for a codec standard, the conformance point is defined at codec-level, instead of tool-level. Different profiles/levels are created for each codec to address the need of different classes of applications. This approach works fine in the past since the application scenarios were quite simple (e.g. DVD, DTV). However, with the exponential growth of new multimedia applications, the old approach of defining conformance point at codec-level becomes awkward. Quite often, a new application designer finds it impossible to find a reasonable codec profile@level to fit the target application well.
For example, the FMO tool of H.264 is useless for many applications but a decoder may still need to support it simply because it is included in AVC baseline profile. In general, application environment is changing faster than an international standard can catch up that there should be a more efficient way of allowing a codec to adapt to new
15
applications while maintaining interoperability among different solutions.
MPEG has recognized this issue and started a new work item called Video Coding Tools Repository (VCTR) in 2004. After some investigations, the direction and benefit of VCTR is becoming clear [2]. Later, this effort becomes the Reconfigurable Video Coding (RVC) framework in 2006 [3]. This new framework defines the conformance point at tool-level. Therefore, in principle, an RVC-enabled codec can negotiate on-the-fly with the video bitstream encoder/sender about which coding tools is required and how the data path can be wired among these coding tools in order to decode the video bitstream. After the setup stage, the decoder can decode the bitstream correctly. With this approach, an SoC can support multiple codec standards as well as creating customized codecs in real time as long as it contains all the standard-conforming tools that is necessary to decode bitstreams from different encoders.
1.1 Introduction to MPEG RVC Framework
The concept of MPEG RVC framework can be illustrated by Fig. 1. The key difference between RVC and the old MPEG codec standards is that the interface of each coding tools is defined precisely so that they can be used (like LEGO blocks) to build various codecs. The decoder configuration describes how input bitstream can be parsed so that the raw input data to each coding tools can be extracted. A decoder description language is under development so that the configuration of a specific codec (such as H.264) can be described using a (small) configuration bitstream. The decoder configuration bitstream will be processed by an RVC decoder before decoding of a video bitstream conforming to the described standard. Note that after processing a configuration bitstream, the RVC decoder will generate a Global Control Unit (GCU) that governs the operation of the coding tools.
applications
H.264 parser &
video composer
MPEG-4 parser
& video composer
8x8 IDCT 4x4 GBT ¼-pel MC 4x4 intra-prediction Old MPEG
conformance point
New RVC conformance point
Tools in RVC Toolbox
H.264 Virtual Network of FUs
MPEG-4 Virtual Network of FUs
MPEG-B
MPEG-C
Fig. 1. Concept of MPEG RVC framework
In principle, the configuration description tells the RVC decoder how to wire the coding tools to form a data path. In the RVC framework, each coding tools is called a functional unit (FU) and is specified in Fig. 2 [1]. In Fig. 2, a control signal is a signal embedded in the video bitstream (for example, the width and height of the video frame). A context signal is a signal generated from the processing of bitstream data (for example, the AC prediction direction in the MPEG-4 Part 2 video standard). The context-control unit reads in the context and control signals generated by previous FU’s and generates (or passes on) some context and control signals to the next FU’s based on the result of the processing unit.
Processing
Context & control [in]
e.g. coding parameters, mode selection signals
Context & control [out]
e.g. derived parameters from the video data Context-Control
Unit
Fig. 2. Definition of a functional unit in RVC
The overall architecture of RVC is shown in Fig. 3. There is a syntax paring FU to parse the bitstream to context and control information and MB-based data. The content and control information is fed to Global Controller Unit(GCU) and data is fed to other MB-based FU to processing. The GCU is responsible for controlling the data
16
path between network of functional units and receiving and passing content and control information to each function units.
Syntax
Parsing FU MB based FU
Content&control info Content&control info
bitstream MB-based data Decoded pixels(MB)
toolbox
Essential Syntax elements
Control
tables GCU
Fig. 3. Overall architecture of RVC
A partial example of a configured RVC codec that behaves like an H.264 baseline decoder is shown in Fig. 4. In Fig. 4, the functional blocks encircled in the dashed rectangles will be implemented using the proposed architecture in next two sections.
Parser
Networks of HW/SW FUs
Encoded Bitstream
slice info QP
Scan-1
Fig. 4. Example of RVC configuration
Currently, the two parts of RVC is defined in two different MPEG internal documents. Namely,
z MPEG-B part 4, Codec Configuration Representation.
z MPEG-C part 4, Video Tool Library.
17
18
The MPEG-B is composed of two elements, the first element is the generic video bitstream description language that can be used to instantiate a parser, and the second element is the language that can be used to specify the network of functional units of the decoder data path. The tools in RVC toolbox is defined in MPEG-C. So far, the RVC framework is still under development in MPEG. Most of the investigations are done using C models and behavioral model simulators such as Moses [4]. In this thesis, we propose a HW platform that can support the RVC framework for construction of a virtual network of FUs (MPEG-B) from a collection of tools (MPEG-C).
The thesis is organized as follows. Some related works are introduced in chapter 2.
And the proposed SoC architecture for supporting the RVC framework is presented in chapter 3. Some comparisons of the RVC architecture with a common hard-wired solution are also given in this chapter. The designs of some HW functional units are shown in chapter 4. The experimental results and analysis are discussed in chapter 5.
Finally, the conclusions and discussions are given in chapter 6.
19