2. System Architecture

2. System Architecture

Figure 38.1 shows a potential scenario of a distributed video storage, management and delivery system. We shall use this to illustrate some interesting aspects of distributed video production, distributed video coding, distributed video processing, and distributed video distribution. In this base model, every user/client can be a video producer/provider, intermediate service provider (e.g., such as of video transcoding), and video consumer.

To further illustrate the distributed video database scenario depicted in Figure 38.1, we use the following example: When a user with a handheld device requests a media file (or a life stream) from the distributed video database system by specifying desired attribute, the underlying P2P infrastructure (MAPS - Media Accelerated Peer Services) issues a distributed query, and returns a list of possible downloads together with their associated transmission and local decoding costs as well as their compression format description such as standard MPEG-1, high-quality MPEG-2, and low bit-rate MPEG-4. The local P2P client aggregates the return list with respect to video quality. It also extends the list by possible lower video formats, which could be achieved by transcoding, and which may be more adequate for the client device. From this list the user selects the desired (and feasible) quality of the video. If the version of the video the user selects already exists in the network, the file is streamed to its destination; if not, the P2P infrastructure transcodes the content. For instance, suppose the user requests an MPEG-4 version of a video clip that exists only in MPEG-2 format, possibly at a different rate and resolution. After performing the search, the P2P system discovers the MPEG-2 version of the requested clip and returns the cost associated with streaming it to the client and decoding it there. In this scenario, it is, firstly, costly to transfer the MPEG-2 sequence over the wireless link and, secondly, the handheld device does not have the computational power to decode and render the sequence in real time. Moreover the device has limited battery life and should not perform transcoding itself even if it is possible. Hence, the P2P infrastructure automatically assigns a peer to perform the transcoding based on a cost evaluation, so that only a low bitrate MPEG-4 version of the video is transferred over the wireless link to the user. This example demonstrates that the system not only takes into account storage capacity and network bandwidth, but also CPU power and battery capacity when needed.

Our proposed system architecture to enable scenarios as described above is depicted in Figure 38.2. Existing P2P infrastructures are extended with several modules. These modules are collated into the Media Accelerating Peer Services (MAPS) [14]. In detail, the software layers in the system can be classified as follows, from bottom to top:

1. The traditional underlying operating system and related services, viz. sockets, RPC, DCOM, etc.

2. The P2P service layer providing basic functionality such as peer discovery, user and group management, name resolution, and delivery primitives. Examples of systems providing some or all of these services are Gnutella, FreeNet [4], and JXTA [9]. MAPS extends this layer with a plug-in architecture for customization of the basic operations of search and delivery. MAPS currently provides two extensions: a module enabling real-time media streaming (via RTP over UDP) and a module for enhanced search capabilities (via distributed SQL).

3. The MAPS video support modules, which use the underlying service layer for network and resource access and which provide transformation and computation services on data obtained from/sent to the layer below. Examples include a support module for MPEG video that provides transcoding support, and a module that automatically analyzes images, videos, and music files on each peer to provide better search capabilities.

4. The application layer.

Figure 38.2: System architecture.

Similar to other P2P environments, a key characteristic of the architecture is the transparency of the physical location of a resource. That is, the location of data, services, and other resources need not be determined explicitly by applications using the provided services. Instead, data and services can exist anywhere in the network, and the system handles their discovery and delivery to the requesting application.