PSL MPEG-2 IPMP-X Reference Software - IPMP Reference Software

Chapter 4 IPMP Reference Software

4.2 PSL MPEG-2 IPMP-X Reference Software

Message Router

Tool Manager MPEG-2 Terminal

Received IPMPDescriptor from PMT, build up control

graph

Setup Input, Output Elementary Streams at specified control point

Instantiate IPMP Tool, update table entry

Receive IPMP Tool List from IPMP Control Info in PSI

Parse IPMP Tool List, resolve Alt list, Param Desc, retrieve tools

Retrieve Tool from Tool Container

Receive Tool Container from IPMP Control Info in PSI

ConnectTool/DisconnectTool

Destroy IPMP Tool, update table entry

Figure 9 MPEG-2 IPMPX system software architecture [4]

Because the MPEG-2 system part is quiet different from the MPEG-4 system part, we only focus on the Message Interface that implemented by PSL. Even the difference exists between the system part of MPEG-2 and MPEG-4, the IPMP messages are the same. The Message Interface of PSL includes the implementation of the IPMP messages that specified in the specification.

Basically, the MPEG-2 IPMP Extension is developed from the MPEG-4 IPMP Extension,

so, they are almost the same except the part associated with the MPEG-2 system and MPEG-4 system.

Figure 9 shows the MPEG-2 IPMPX system software architecture, and the architecture is familiar to the one in MPEG-4.

Here, we do not concern about the APIs of every module within the MPEG-2 IPMPX system. However, what we focus on is the IPMP Message structure of the IPMPX system developed by PSL. In general, we can view the top class of the whole structure as the class named BitField. All the data structure within the implementation should be turned into binary data, so all the classes inherit from the BitField class for the translation between data structure and the binary data. In the BitField class, there are four member functions that are declared as pure virtual functions. All the classes that inherit from it must implement these functions.

They are listed as follows including the functionalities of them.

/**

* reads the data from the buffer and stores the fields internally.

* Must be implemented in derived classes.

* @param buf the buffer to read

* @return the number of bits that have been read from the buffer

virtual int fromBuffer(const byte* buf) = 0;

/**

* writes the internal fields into the buffer * @param buf the buffer to write

* @return the number of bits that have been written into the buffer

virtual int toBuffer(byte* buf) = 0;

/**

* checks if the syntax is correct.

* @return true if the syntax is correct.

virtual bool checkSyntax() const = 0;

/**

* this method must be implemented in derived classes so that it returns the * size in bytes of the binary message generated by the toBuffer method.

* @return the size (in bytes) of this class.

virtual unsigned int getSize() const = 0;

Then, the classes of the second layer are divided into many branches. Here, we only

focus on the classes associated with the IPMP Messages, the ExpandableBaseClass. In the ExpandableBaseClass, the virtual functions of BitField are implemented and it provides another pure virtual function in order to compute the size of this object when serialized into a bitstream. The declaration of the function is shown below including the description.

/**

* Compute the size (in bytes) of this object when serialized into a bitstream, according * to the current content of the member variables.

* This method must be overloaded by any derived class to indicate the correct size.

* This size does NOT include the object_id and the length of the ExpandableBaseClass.

* @return the size in bytes.

virtual unsigned int sizeOfInstance() const = 0;

There is a special object named Length contained in the ExpandableBaseClass. The Length class is also inherits from the BitField class. This object is to record the total size of the object that inherits from the ExpandableBaseClass. The Length object has its size vary from one to four bytes. In the current byte, if there are any concatenating bytes presenting the length of the object, the first bit of the current byte will be true. So, the maximum size of the object length is 2²⁸ bytes.

There are several branches expanded from the ExpandableBaseClass. They are BaseDescriptor, ByteArray, IPMP_Data_BaseClass, IPMP_DeviceMessageBase, and IPMP_ToolMessageBase.

The IPMP_DeviceMessageBase and IPMP_ToolMessageBase are the two kinds of basic IPMP Messages that contain the IPMP information as described in section 2.3.2. The IPMP_ToolMessageBase will contain the object IPMP_StreamDataUpdate inheriting directly from the BitField. And there are several classes that inherit from the IPMP_ToolMessageBase.

They are IPMP_DescriptorFromBitstream, IPMP_MessageFromBitstream, and IPMP_MessageFromTool. And they are all designed to contain the IPMP information as their loads.

Several classes inherit from the class IPMP_Data_BaseClass. They are the classes that represent different IPMP information such as IPMP_GetTools, IPMP_GetToolResponse, and etc. They have the name the same with tags that extended from the IPMP_Data_BaseClass that is described in section 2.3.1.

Figure 10 Class hierarchy of message interface of PSL IPMPX reference software

Figure 10 shows the overall inherent relationship between classes within PSL MPEG-2 IPMP Extension reference software.

Chapter 5 MPEG-4 IPMP Extension System Implementation on MPEG-21 Test Bed

This chapter describes our implementing of the MPEG IPMP Extension system on the MPEG-21 test bed. Because of the existing architecture of the MPEG-21 Testbed, we have to design an architecture that matches the MPEG-21 test bed. This software architecture is modified from the MPEG-4 IPMP Extension system in IM1 and the MPEG-2 IPMP Extension system developed by PSL. However, the entire system has been restructured and the software is rewritten. The redesigned architecture contains mainly six modules. They are Message Router, Tool Manager, Terminal, IPMPFilter, Context, and IPMP Tool. The relationship among these modules is shown in Figure 11.

Figure 11 Relationships among modules in the IPMPX system

Here we focus on the modules, Context and IPMP Filter, because the functionalities of the others have been described in the previous sections. First, we describe the concept of the Context object. Then, we give the details about the design of the IPMP Filters. Next, the design of Message Router, Tool Manager, Terminal, and the IPMP Tool are discussed.

Because MPEG-21 Testbed is separated into two sides, the Client side and the Server side, when we discuss the IPMP subsystem, we will point out the differences between the designs in both sides. Although, basically, the IPMP systems at the Client and the Server sides are

almost the same, there still some differences between them. We will also discuss the design the APIs of modules related to the IPMP subsystem.

5.1 Architecture Design

5.1.1 Context

Because there are many pieces of shared information among the modules in the IPMP system, we move all the shared information to an entity called Context rather than distributing them into individual modules. These modules including Tool Manager, Message Router, Terminal, IPMP Filters, and IPMP Tools, are connected to the Context in order to retrieve the shared information. The relationships between these modules and the Context are shown in Figure 11.

Figure 12 Context hierarchy

The Context is designed as a tree structure for easily navigating the associated shared data in it. In our design, the Context can be split into four levels, Top Context, Object Context, ES Context, and Tool Context. And the relationships between the four levels of Context are shown in Figure 12.

references to Tool Manager, Message Router and Terminal. And it also bookmarks the map of the IPMP Tool Descriptor. The Context of the object level is empty in our design. In the Context at ES level, we store the information about the ES Descriptor and the references to all the IPMP Filters within the IPMP system. The bottom level of the Context in the tree structure is the Context of Tools. It records the information of the Tool Descriptor and the references to the IPMP Tools.

In order to construct the tree structure of the IPMP Context, the Contexts at any levels has the following five members, context ID, context type, parent context, children context, and top context. The context ID serves as the identifier of this context. The context type records what type the context is. The parent context and children context are the links to the tree structure. For instance, for an IPMP ES Context, it has the children contexts as Tool Contexts, and the parent context as the Object Context. We show the tree structure of the Context and its links in Figure 13. The arrow with the symbol, *, denotes that there may be multiple objects.

Figure 13 Links between four level contexts

As shown in Figure 13, the Context has a tree structure, and we can easily find the shared information by navigating through the context tree. The links of the context tree are discussed earlier, now we discuss the links of the contexts and the shared entity. There are different types of members in the contexts depending on the context type. Figure 14 shows the

relationships of modules of IPMP system and the four level Contexts. From the Figure 14, we observe that it is easy to find the component of the IPMP system by searching the context tree.

Figure 14 Search the context tree

Figure 15 Relationship between IPMP Context and other modules

From the link diagram shown in Figure 14, for instance, if there is an IPMP Tool A that

in the Top Context, then it passes the message to the Message Router. After receiving and determining the recipient of this message, the Message Router identifies the IPMP Tool B in the Context tree, from Top to Object, from Object to ES and from ES to Tool. Then it routes the message to the IPMP Tool B. The method to find the other components is the same.

The relationship between the IPMP Context and other modules associated with IPMP Subsystem is shown in Figure 15. All modules associated with the IPMP Subsystem have relationship with IPMP Context.

5.1.2 IPMP Control Points (IPMP Filters)

Considering the original architecture of MPEG-21 Testbed, it is important to choose the appropriate IPMP Control Points and insert the IPMP Filters at those locations. By surveying the MPEG-21 Testbed, we finally allocate three IPMP Control Points on the MPEG-21 Testbed, one at the server side and the other two at the client side.

The IPMP Control Points at client side are allocated between the Stream Buffer and the Decoder, and between the Decoder and Output Buffer. In Figure 2, there is an IPMP Control Point defined in between the Decoder Buffer and the Decoder. It is mapped to the one between the Stream Buffer and the Decoder (PreDecoderFilter) in our design. And there is also one IPMP Control Point defined between the Decoder and the Composition Buffer in Figure 2. However, there is no Compositor designed in MPEG-21 Testbed, so we mapped this IPMP Control Point to the one between the Decoder and the Output Buffer (PostDecoderFilter).

Since the specification of MPEG-4 IPMPX mainly focuses on the client side only, our design on the server side is inferred from the client side design. The PreDecoder Filter at client side is mapped to the IPMP Control Point between the DIA module and Streamer at server side and is called PostDIAFilter. In current implementation, we insert an IPMP Tool to perform the decryption in PreDecoderFilter at client side, and an IPMP Tool for real-time encryption in the PostDIAFilter at server side.

The IPMP Control Point between the Decoder and the Output Buffer at client side has no corresponding IPMP Control Point at server side. It is because the encoding of the media content is done offline and the encoded media contents are stored in the module called Media Database before streaming. In theory, the PostDecoderFilter is mapped to an IPMP Control

Point between the encoder and the module providing the un-coded media content. The main purpose of PostDecoderFilter is to extract or determine the watermarking of the un-coded media content. In current design, we could perform watermarking insertion off-line, and extract it by the PostDecoderFilter.

Figure 16 shows the relationships between the IPMP Control Points and IPMP system and the modules related with the IPMP system at client side. Because the Decoder in the MPEG-21 Testbed is designed base on the MPEG-4 reference decoder, it is not a passive decoder. In other words, the Decoder is an active device that retrieves the stream data from the Stream Buffer and puts the decoded data to the Output Buffer. The original concept of IPMP Control Points is that they are somewhat like filters to filter the passing bitstream data.

However, in the MPEG-21 Testbed, the filter concept does not fit well here, and we have to design the IPMP Control Points using the concept of processor.

Figure 16 Block diagram of IPMPX system at client side

Since the Decoder is an active component, it decides the actions of getting the data and putting the decoded data. Hence, we design these two IPMP Filters as processors that are attached to the Decoder, and process the bitstream data as similar to the function of the Decoder. The Decoder retrieves the bitstream data from the Stream Buffer then passes data to the PreDecoderFilter immediately before decoding it. After being processed by the

PreDecoderFilter, the data are then returned to the Decoder and are decoded by the Decoder.

Before putting the data to the Output Buffer, the Decoder shall pass the decoded data to the PostDecoderFilter for processing, and then puts the returned data to the Output Buffer.

Figure 17 Block diagram of IPMPX system at server side

Because the size of the data passed to the PreDecoderFilter and of the data processed by PreDecoderFilter may be not the same, the Decoder may crash when gets data of the different size. In order to avoid this problem, we modify slightly the Decoder by inserting a buffer named “decoder buffer” into Decoder. Note here that the decoder buffer is not the Decoder Buffer appear in the specification, but a simple buffer to buffer the bitstream data for the Decoder before decoding. Therefore, this modification does not affect the software in terms of satisfying the MPEG-21 Testbed specifications. The decoder buffer holds the data for the Decoder so that the size of the data requested by Decoder is unchanged to prevent the Decoder from crashes. In the original Decoder design, the operation of data access from the Stream Buffer is spread over the entire decoding procedure, but this arrangement makes the insertion of IPMP devices complicated. The inserted buffer collects the spread operations of data access to ease the management of IPMP. The modification is show in Figure 18.

At server side, the design of the IPMP Filter, PostDIAFilter, is similar to that at client side. And the relationships between the modules associated with the IPMP system and the IPMP Control Points are shown in Figure 17. Here, the Streamer is an active module. So the

PostDIAFilter processes the bitstream as Streamer’s will. The procedure of processing the bitstream data is similar to that at client side.

Figure 18 Modification of Decoder

Nowadays, the design trend of the decoder is moving toward passive decoder in recent streaming system. And the concept of filter is fit in such kind of system. However, in MPEG-21 Testbed, the decoder is designed as an active decoder, so the concept of the filter is not proper within. Therefore, in our design, we have to adapt the design scheme of processors.

5.2 Design and Implementation of Software

In the architecture of MPEG-21 Testbed shown in Figure 5, only three IPMP modules are visible in the architecture. Two of them, PostDecoder Filter and PreDecoder Filter, are at the Client side and the other one, PostDIA Filter, at the Server side. However, there are other important modules that integral parts of IPMP system. They are Message Router, Tool Manager, IPMP Tools, and the Terminal. Here, we discuss the API design and the implementation issues of the IPMP system in MPEG-21 Testbed module by module.

5.2.1 Message Router

The relationship between the Message Router and other modules is shown in Figure 19.

Figure 19 Relationship between Message Router and other modules

The Message Router of IPMP system in the MPEG-21 Testbed has four main tasks. The Message Router here has to process the IPMP Tool Descriptor whenever the Terminal receives it. The IPMP Tool Descriptor may come from the IOD or from the bitstream. At the Server side, the IOD is stored in a file along with the media file. Before accessing the media file, the Server has to access the IOD file of the requested media file for setting up the streaming system and the IPMP system at the Server side. When the Terminal accesses the IOD, it parses the IOD and then passes IPMP Tool Descriptor, ES Descriptor, and IPMP Tool Descriptor Pointer to the Message Router for processing. The Message Router processes IPMP Tool Descriptor in order to get the IPMP information, some for initializing IPMP Tools, and routes it to the corresponding IPMP Tools. Moreover, after parsing the IPMP Tool Descriptor, the Message Router informs the Tool Manager to connect the IPMP Tools to specified location according to IPMP Tool Descriptor.

The Message Router also has to process the ESD coming from the Terminal in order to parse the IPMP Tool Descriptor Pointer within it. The IPMP Tool Descriptor Pointer included

in the ESD indicates the existence of an IPMP Tool with its description as the IPMP Tool Descriptor pointed by the IPMP Tool Descriptor Pointer in the ES. The location within ES is indicated by the control point code and sequence code within the IPMP Tool Descriptor.

Figure 20 The messaging procedure

During the content consumption, there may be many run-time messages carrying the IPMP information generated by the IPMP Tools or coming from the bitstream. The Message Router has to receive these messages and routes them to corresponding IPMP Tools, Terminal, or other IPMP Devices. A possible scheme for the generating, routing, and receiving of the message is shown in Figure 20. In Figure 20, the Server means the server system of Testbed including the IPMP system at server side, and the Client means the client system including the IPMP system at the client side. In the client-server messaging scheme, first, one of the IPMP Tools at server side generates an IPMP message that has to be sent to one of the IPMP Tools at the client side. The message is then passed to the Message Router. The Message router receives the message from the IPMP Tool and determines that if the recipient of the message is at server side. If the recipient of this message is locally available, the Message Router

在文檔中 MPEG-4 IPMPX系統在MPEG-21測試平台上的設計與實現 (頁 42-0)