MediaBroker

Vision

In the evolving world of distributed computing, multimedia data poses a significant challenge as it flows from arbitrary sources to disparate sinks. MediaBroker attempts to create a standard infrastructure for linking media sinks to media sources on the open range of the network. By combining facility for centralized data management with individual, programmer specified, media transformation code, MediaBroker allows distributed media sinks to request media in a format of their choosing regardless of who else might be using the media stream.



Figure 1, This figure demonstrates a simple distribution of multimedia sources in the home. Each source is directed to multiple media sinks for consumption. MediaBroker facilitates such distribution --of devices AND media.


Applications

The rich multimedia environment of todays highly connected smart spaces allows the mind to run wild with possible uses for such multimedia distribution infrastructures. As an example, we have implemented a software intercom system in Georgia Tech's Aware Home which allows conversational interaction across traditional home boundaries (i.e. walls, doors).



Figure 2, The current GUI for the Family Intercom allows simple visualization of where in the home users are. The users can then be connected via audio channels provided by nearby Microphone/ Speaker media nodes.


The Family Intercom, described more thoroughly here, leverages existing locationing infrastructure in the Aware Home to allow conversational connection to follow users as they move from room to room.

The MediaBroker also provides distributed media discovery, storage, and dissemination for the EventWeb project.

Research

MediaBroker, a multimedia transfer and access infrastructure aimed at speeding development of multimedia rich smart-spaces, has been in development at The Georgia Institute of Technology for over a year. What began nearly two years ago as a distributed surveillance application built on D-Stampede has blossomed into a complete infrastructure with a mature API and a nearly mature code base. The MediaBroker System encompasses a central MediaBroker cluster and distributed MediaBroker client nodes. The MediaBroker attempts to provide a common multimedia access infrastructure to all interested parties. MediaBroker accomplishes this using software multicast to share multimedia data with all interested multimedia consumers and also through the use of soft-pluggable media transformation routines that allow MediaBroker to ship the same multimedia data in multiple formats to different consumers. All multimedia in MediaBroker is tagged with a data type. These data types are arbitrarily defined name/value pairs describing a data format. As multimedia is transmitted through the system, MediaBroker transforms it from its initial data type to best match the requested type using data transformation filters corresponding to pairs of input/output name/value pairs.

Data Transfer

The MediaBroker uses individual "data brokers" to handle media transfer from media producers to media consumers. The animation below demonstrates how each data broker serially delivers media from producers to requesting consumers. The serial nature of media delivery demonstrated in the animation requires that the data broker pause all delivery when a producer or consumer requests a new type of data. This pause is the result of the calculations necessary to reconfigure the delivery path. These pauses are fairly insignificant (~300 microseconds) and, with the semantics of media delivery, will not upset the delivery of media in the long term.
Figure 3, Data Broker Animation

Data Typing

Each data stream in MediaBroker is associated with a specific data type describing the stream's data. MediaBroker uses the stream's data type to know how to handle the data inside the stream. Programmers supply arbitrarily defined data types ordered in lattices to MediaBroker. Each lattice edge connecting data types is associated with a data type transformation. An example type lattice is shown in Figure 4 below. The figure shows two consumers requesting two distinct data types (the blue squares). MediaBroker will then ask the media producer to produce its data at a quality higher than is requested to preserve fidelity on conversion. MediaBroker can ask for any higher data type (the green squares). To preserve fidelity while still using the least possible resources, one of MediaBroker's goals, MediaBroker chooses the least of the higher quality options; MediaBroker chooses the Least Upper Bound to all requested types (the red square).


Figure 4

Performance Analysis

A more thorough analysis of the performance characteristics of our MediaBroker implementation is available in the paper; here we will discuss the result we are proudest of: MediaBroker's scalability. We examined how MediaBroker would scale both with respect to the number of media streams being transfered from a single producer to a single consumer and with respect to the number of consumers attaching to a single producer. This first (Figure 5) graph shows the average latency of packet transfer across MediaBroker from a single producer to a single consumer. The graph varies across the number of streams in the system from 1 to 64. The second graph (Figure 6) shows both total system throughput as well as individual stream throughput of packet transfer when the system is handling first 1 stream up to 64 streams. The next set of graphs (Figures 7 and 8) also show average latency and throughput but varied across the number of consumers attached to a single producer.



Figure 5

Figure 6

Figure 7

Figure 8

Current Work

In addition to continuing work on MediaBroker-based applications (Family Intercom and EventWeb), we are upgrading existing MediaBroker design and implementation.

Publications

We presented our work at Percom '04 in a paper titled "MediaBroker: An Architecture for Pervasive Computing":

Collaborators