Managing Real-Time Distributed Multimedia Applications

Managing Real-Time Distributed Multimedia Applications 1 Chapter I Managing Real-Time Distributed Multimedia Applications Vana Kalogeraki Hewlett Packard Laboratory, USA Michael Melliar-Smith and Louise E. Moser UC Santa Barbara, USA Distributed multimedia applications are characterized by timing constraints and end- to-end quality of service (QoS) requirements, and, therefore need efficient management mechanisms to respond to transient changes in the load or the availability of the resources. This chapter presents a real-time distributed multimedia framework, based on the Common Object Request Broker Architecture (CORBA), that provides resource management and Quality of Service (QoS) for CORBA applications. The framework consists of multimedia components and resource management components. The multimedia components produce multimedia streams, and combine multimedia streams generated by individual sources into a single stream to be received by the users. The resource management components provide QoS guarantees during multimedia transmissions based on information obtained from monitoring the usage of the system’s resources. INTRODUCTION Real-time distributed multimedia environments have set forth new challenges in the management of processor and network resources. High-speed networks and powerful end- systems have enabled the integration of new types of multimedia applications, such as, video-on-demand, teleconferencing, distance learning and collaborative services, into today’s computer environments. Multimedia applications are variable in nature, as they handle a combination of continuous data (such as audio and video) and discrete data (such as text, images and control information) and impose strong requirements on data transmis- sion, including fast transfer and substantial throughput. Copyright © 2002, Idea Group Publishing. 2 Kalogeraki, Melliar-Smith & Moser The technical requirements necessary to achieve timeliness are obviously more difficult to satisfy in distributed systems, mostly because of the uncertain delays in the underlying communication subsystem. This difficulty is further exacerbated by the hetero- geneity of today’s systems with respect to computing, storage and communication resources and the high levels of resource sharing that exist in distributed systems. Multimedia tasks may involve components located on several processors with limited processing and memory resources and with shared communication resources. Different transport mechanisms, such as TCP or UDP can be used for data transfer within local- or wide-area networks. Distributed object computing (DOC) middleware is software built as an independent layer between the applications and the underlying operating system to enable the applica- tions to communicate across heterogeneous platforms. At the heart of the middleware resides an object broker, such as the OMG’s Common Object Request Broker Architecture (CORBA), Microsoft’s Distributed Component Object Model (DCOM) or Sun’s Java Remote Method Invocation (RMI). Multimedia technologies can take advantage of the portability, location transparency and interoperability that middleware provides to enable efficient, flexible and scalable distributed multimedia applications. Developing a system that can provide end-to-end real-time and QoS support for multimedia applications in a distributed environment is a difficult task. Distributed multimedia applications are characterized by potentially variable data rates and sensi- tivity to losses due to the transmission of data between different locations in local- or wide-area networks and the concurrent scheduling of multiple activities with different timing constraints and Quality of Service (QoS) requirements. Several QoS architec- tures (Aurrecoechea & Campbell & Hauw, 1998) that incorporate QoS parameters (such as response time, jitter, bandwidth) and QoS-driven management mechanisms across architectural layers, have emerged in the literature. Examples include the QoS Broker, COMET’s Extended Integrated Reference Mode (XRM), the Heidelberg QoS model and the MAESTRO QoS management framework. Providing end-to-end QoS guaran- tees to distributed multimedia applications, requires careful orchestration of the proces- sor resources, as multimedia interactions may lead to excessive utilization and poor quality of service and multimedia applications can easily suffer quality degradation during a multimedia session caused by network saturation or host congestion. Efficient management of the underlying system resources is therefore essential to allow the system to maximize the utilization of the processors’ resources and to adapt to transient changes in the load or in the availability of the resources. The goals of this chapter are to present a distributed framework for coordinating and managing the delivery of real-time multimedia data. The framework manages the transmis- sion of real-time multimedia data and uses current resource measurements to make efficient management decisions. CORBA The Common Object Request Broker Architecture (CORBA) (Object Management Group, 1999) developed by the Object Management Group (OMG) has become a widely accepted commercial standard for distributed object applications. CORBA provides an architecture and platform-independent programming interfaces for portable distributed object computing applications. The CORBA core includes an Object Request Broker (ORB) which acts as the message bus that provides the seamless interaction between client and server objects. CORBA  Managing Real-Time Distributed Multimedia Applications 3 Interface Definition Language (IDL) describes the functional interface to the objects and the type signatures of the methods that the object embodies. IDL interfaces are mapped onto specific programming languages (e.g., Java, C/C++, etc.). From the IDL specifications, an IDL compiler generates stubs and skeletons that are used for the communication between the client and server objects. Both the implementation details and the location of the server object are kept hidden from the client objects. Interoperability is achieved using the General Inter-ORB Protocol (GIOP) and the TCP/IP-specific Internet Inter-ORB Protocol (IIOP). CORBA’s independence from programming languages, computing platforms, and network- ing protocols makes it highly suitable for the development of distributed multimedia applications and their integration into existing distributed systems. RELATED WORK Because of its general applicability, the OMG streaming standard (Object Manage- ment Group, 1997) has provoked interest in areas such as telecommunications, biomedicine, entertainment and security. McGrath & Chapman (1997) have successfully demonstrated that the A/V streaming specification can be used for telecommunication applications. Mungee & Surendran & Schmidt (1999) have developed an audio/video streaming service based on the OMG’s A/V Streams model. Several researchers have focused in providing QoS support for distributed multimedia applications. Hong & Kim & Park (1999) have defined a generic QoS Management Information Base (MIB) which consists of information objects that represent a set of layered QoS parameters, organized into four logical groups: service, application, system and network. Le Tien & Villin & Bac (1999) have used m-QoS and resource managers responsible for the QoS mapping and monitoring of multimedia applications and for managing the QoS of the resources. Waddington & Coulson (1997) have developed a Distributed Multimedia Component Architecture (MCA) that extends the CORBA and DCOM models to provide additional mechanisms and abstractions for continuous networked multimedia services. MCA exer- cises the use of those foundation object models by using object abstractions in the form of interfaces to encapsulate and abstract the functionality of multimedia devices and processing entities. MCA presents a solution which incorporates support for real-time continuous media interactions; configuration, control and QoS management of distributed multimedia ser- vices; dual control/stream interfaces and support for basic multimedia object services, including event handling, timer and callback services. Szentivanyi & Kourzanov (1999) have provided foundation objects that define different aspects of multimedia information management. Their approach is built on two notions: (1) a model that covers all related aspects of media management, such as storage, streaming, query, manipulation and presentation of information of several media-types, and (2) a distributed architecture that provides distribution, migration and access for the object model and its realization in a seamless, configurable and scalable manner. Several research efforts have concentrated in enhancing non-CORBA distributed multimedia environments with resource management capabilities. Alfano & Sigle (1996) discuss the problems they experienced at the host and network levels when executing multimedia applications with variable resource requirements. Nahrstedt & Steinmetz (1995) have employed resource management mechanisms, emphasizing on host and network resources, to guarantee end-to-end delivery for multimedia data transmission and to adapt 4 Kalogeraki, Melliar-Smith & Moser when system resource overloading occurs. Rajkumar & Juvva & Molano & Oikawa (1998) have introduced resource kernels to manage real-time multimedia applications with different timing constraints over multiple resources. OVERVIEW OF THE MULTIMEDIA FRAMEWORK Desired Features Our CORBA framework for managing real-time distributed multimedia applications is responsible for dynamic QoS monitoring and adaptation over changing processor and network conditions. End-users receive multimedia streams from different sources without the need to know the exact location of the sources or to have specialized processors to capture the multimedia data. The framework satisfies QoS requirements expressed by the users through a combination of system design choices (e.g., assigning priority/importance metrics to the multimedia objects) and physical configuration choices (e.g., allocating memory and bandwidth). The framework has the following design objectives: 1. To reduce the cost and difficulty of developing multimedia applications. End users should be engaged with a convenient way of expressing their QoS requirements without having to address low-level implementation details. Information such as the port number or the host address of the endpoints should be kept transparent to the users. 2. To satisfy the QoS requirements and to meet the timing constraints specified by the users. User QoS requirements are translated into application-level parameters and are mapped into requirements for system-level resources. Providing QoS-mapping mecha- nisms is beneficial to the system because it is more systematic and therefore can largely reduce potential user errors. Monitoring functions determine QoS violations that can cause quality degradation and lead to poor system performance. 3. To coordinate the transmission and synchronization of multimedia streams. Live synchronization requires both intra-stream and inter-stream synchronization (Biersack & Geyer, 1999). Intra-stream synchronization refers to maintaining continuity within a single multimedia stream, while inter-stream synchronization refers to preserving the temporal relationships between media units of related streams. Live synchroniza- tion requires the capture and playback/display of multimedia streams at run-time and, therefore, can tolerate end-to-end delay on the order of a few hundred milliseconds. 4. To balance the load on the resources and to minimize system overheads. Dynamic configuration management is essential to deal with complex, scalable and evolving multimedia environments. Multimedia objects must be distributed evenly across the processors with respect to their resource requirements and dependency constraints. Structure of the Framework The framework manages multimedia applications and the underlying system resources in an integrated manner. The framework consists of multimedia components for managing the transmission and delivery of multimedia data and resource management components for managing the multimedia components and monitoring the underlying system resources, as shown in Figure 1.  Managing Real-Time Distributed Multimedia Applications 5 Figure 1: The architectural components of the framework The multimedia components consist of Suppliers that produce streams of multimedia data, a Coordinator that receives multimedia streams from different sources and combines them into a single stream, and Consumers that receive a single stream and separate the different flows in the stream for individual playback or display. The resource management components consist of Profilers that measure the usage of the resources, Schedulers that schedule the tasks of the multimedia objects and a Resource Manager that allocates the multimedia objects to the processors and takes appropriate actions to satisfy resource requirements. The Resource Manager is implemented as a set of CORBA objects that are allocated to various processors across the distributed system and replicated to increase reliability; logically, however, there is only a single copy of the Resource Manager. The Resource Manager maintains a global view of the system and is responsible for allocating the multimedia objects to the processors. The Resource Manager works in concert with the Profilers and the Schedulers. The Profiler on each processor monitors the behavior of the multimedia objects and measures the current load on the processors’ resources. It supplies information to the Resource Manager, which adapts the allocations over changing processing and networking conditions. The Scheduler on each processor exploits the information collected from the Resource Manager to schedule the multimedia objects on the processor. The multimedia components of the framework are implemented as a set of CORBA objects. The Resource Manager decides the location of those objects across the system based on the utilizations of the processors’ resources, the users’ QoS requirements and the communication among the multimedia objects. The Coordinator uses a reliable totally- ordered group communication system to multicast the multimedia data to the Consumers to achieve synchronization of the streams. 6 Kalogeraki, Melliar-Smith & Moser QUALITY OF SERVICE FOR DISTRIBUTED MULTIMEDIA APPLICATIONS Quality of Service (QoS) represents the set of those quantitative and qualitative characteristics that are needed to realize the level of service expected by the users (Vogel & Kerherve & Bochmann & Gecsei, 1995). There are typically many layers that determine the actual end-to-end level of service experienced by an application. User QoS parameters are translated into application level parameters and are mapped into system-level (processor, network) parameters to control the system resources. The QoS mapping is still an open research issue, largely because there are numerous ways (Alfano & Sigle, 1996) to describe QoS for each layer. The QoS mapping is performed by the resource management compo- nents of the framework, which enables the user to specify QoS requirements without having to map the QoS parameters into parameters for the underlying layers. The QoS parameters are expressed as (name,value) pairs. User QoS Parameters To enable users to express their QoS requirements in a simple and convenient manner, a graphical user interface is provided. User QoS parameters are specified in terms of a level of service (such as best effort or best quality) or properties that the user requires. The user must be prepared to pay a higher price when higher Quality of Service is desired. For example, a high-resolution video stream incurs a higher price in terms of increased delivery delay. User QoS requirements are expressed in terms of the media type (i.e., audio or video) and a set of media format parameters such as the color space or the data size (i.e., width and height) of an image, or the compression technique for the frames of a video stream. Users can also specify timing constraints such as start and end delivery times, the desired rate of transmission, the worst-case end-to-end delay and the maximum jitter. The QoS specified by the user includes media-specific parameters, if additional hardware or software con- straints are imposed. Application Layer Application QoS parameters describe the characteristics of the media requested for transfer. Some of the user’s parameters (e.g., end-to-end delay, rate of transmission) can be used directly as application QoS parameters, while others are translated into QoS parameters for the application. For example, for a video stream, the frame size is determined by the image height, width and color of an uncompressed image as specified by the user, and is computed as Frame_size = Width * Height * Color_resolution. A multimedia application has an associated level of service metric, which is explicitly defined by the user or is determined by the resource management components of the framework based on the user’s QoS parameters and the other multimedia applications running in the system. In addition, priority metrics can be associated with the multimedia application as a whole or as individual frames. For example, in MPEG compression, video I-frames contain the most important information and, therefore, should have a higher priority than P-frames or B-frames. Application QoS parameters may also include media-specific information, such as the format of the video source (i.e., PAL or NTSC), the pixel data type, the compression pattern (i.e., IBP pattern for MPEG-1 compression), the bit rate and the number of images to be skipped between captures for a video transmission. The rate of  Managing Real-Time Distributed Multimedia Applications 7 transmission can be derived from the IMAGE_SKIP parameter and the format of the video source. The maximum number of buffers determines the maximum number of images that a video card can store. System Layer While perception of QoS can vary from user to user and from application to application, user and application QoS requirements must be translated into system param- eters in order to monitor and control the system resources. The processor layer determines whether there are sufficient resources to accommodate the user and application requirements. Typical parameters of this layer are the utilization of the CPU, the size of the memory, the available disk space, and the load imposed by special devices used for multimedia processing. This layer also encompasses the scheduling strategy used to schedule the multimedia objects on the processors’ resources. The network layer determines the transport requirements for the multimedia applica- tion, including the transport protocol to be used for the delivery of packets, and packet- related parameters such as packet size, priority, ordering, transfer rate, round-trip delay, packet error and loss rate. Different multimedia streams experience random delays in the delivery of multimedia data due to the heterogeneity of the underlying communication infrastructure. Ideally, the network would deliver the multimedia data as they are generated with minimal or bounded delay. DEVELOPING A DISTRIBUTED MULTIMEDIA FRAMEWORK FOR CORBA CORBA A/V Streaming Specification The CORBA A/V streaming specification (Object Management Group, 1997) defines a basic set of interfaces for implementing a multimedia framework that leverages the portability and flexibility provided by the middleware. The principal components of the framework are: 1. Multimedia Device (MMDevice): A multimedia device abstracts one or more items of hardware. Typical multimedia devices can be physical devices, such as a microphone, a video camera or a speaker, or logical devices, such as a video clip. A MMDevice can potentially support a number of streams simultaneously. For each individual stream, a virtual device and a stream endpoint connection are created. 2. Virtual Device (Vdev): A virtual multimedia device represents the device-specific aspects of a stream. Virtual devices have associated configuration parameters, such as the media format and the coding scheme of the transmitted stream. For instance, a video camera might be capable of transmitting both JPEG and MPEG formats in the data streams. A multimedia device can contain different virtual multimedia devices with different characteristics, and different virtual devices can refer to the same physical device. 3. Stream Endpoint (StreamEndPoint): A stream endpoint terminates a stream within a multimedia device and represents the transport-specific parameters of the stream. A stream endpoint specifies the transport protocol and the host name and port number of the transmitting endpoints. 8 Kalogeraki, Melliar-Smith & Moser 4. Stream: A stream represents continuous media transfer between two or more virtual multimedia devices. Each stream is supported by the creation of a virtual multimedia device and a stream endpoint connection representing the device specific and network specific aspects of a stream endpoint. A stream may contain multiple flows, each flow carrying data in one or both directions. 5. Stream Controller (StreamCtrl): A stream controller abstracts continuous media transfer between virtual devices. It supports operations to control (start, stop) the stream as a whole or the individual flows within the stream. The StreamCtrl interface is used by the application programmer to set up and manage point-to-point or multipoint streams. Our framework uses the components of the A/V streaming specification as building blocks for the multimedia components. The advantage is that the A/V streaming specifica- tion allows the framework to hide the underlying implementation details. Multimedia Components of the Framework Figure 2 shows the UML representation of the multimedia components of the framework. The multimedia components are based on a three-layered object structure. Multimedia suppliers and consumers are represented by the Supplier and Consumer objects, respectively. Multimedia streams that originate from different Suppliers are transmitted to the Coordinator object for multiplexing as a single stream before being forwarded to the Consumers. The Coordinator object is a key component of our framework. It is responsible for the synchronization of the streams that the user wishes to receive so that individual buffers at the endpoints are not required. The Supplier The Supplier (Figure 3) represents the stream endpoint from which the multimedia data are derived. The Supplier defines the media to be transferred using the MMDevice interface. Typical configuration parameters of the MMDevice object are the type (i.e., video camera, microphone) or the name (i.e., “Star Wars”) of the media. The Supplier is implemented as a CORBA object and, therefore, can be located on any of the processors, but typically is associated with the physical location of the multimedia device. For example, to obtain live images from a camera or to listen to a live conversation, specific physical devices must be selected. On the other hand, to playback a video clip from a file, any of the processors can be chosen. The Supplier uses the virtual multimedia device (VDev) object to configure the specific flow transfer (i.e., by setting the video format for a video transfer) and the StreamEndPoint object to define the host address where the Supplier is located. The Coordinator The Coordinator (Figure 4) multiplexes different streams originating from different sources into a single stream to be transmitted to the Consumers. Specific transport parameters are associated with the Coordinator through the StreamEndPoint interface. These parameters define the host address where the Coordinator is located and the port number to which it listens. To accommodate a large number of consumers, different Coordinator objects can be configured to receive different multimedia streams. The Coordinator is an essential component of the framework and, therefore, is replicated for fault tolerance (Kalogeraki & Gunopulos, 2000).  Managing Real-Time Distributed Multimedia Applications 9 Figure 2: UML representation of the multimedia components of the framework Figure 3: The Supplier 10 Kalogeraki, Melliar-Smith & Moser Figure 4: The Coordinator Figure 5: The Consumer The Consumer The Consumer (Figure 5) receives a single stream of multimedia data from the Coordinator and separates the flows that originate from different sources. These flows are subsequently supplied to video and audio buffers to be viewed or played, respectively. Compressed video images must be decompressed before they are displayed by the Con- sumer. The Consumer is associated with the MMDevice interface, where multiple VDev objects can be created to represent the various flows that the object is expected to receive. Typical parameters of the VDev object are image displays and speakers. The host address where the Consumer is located is defined using the StreamEndPoint interface. RESOURCE MANAGEMENT Multimedia applications have high resource requirements, and lack of resource management mechanisms can lead to transmission problems with multimedia objects competing for limited unmanaged resources. Pre-planned allocations are usually not  Managing Real-Time Distributed Multimedia Applications 11 efficient because they can result in overloaded resources as the multimedia environment evolves over time. To provide efficient delivery of multimedia data, the framework employs resource management components that consist of a Profiler and a Scheduler for each processor and a global Resource Manager for the system (Kalogeraki & Moser & Melliar- Smith, 1999). The Profilers The Profiler for each processor measures the current load on the processor’s resources (i.e., CPU, memory, disk) and the bandwidth being used on the communication links. The Profiler also monitors the messages exchanged between the objects and uses the information extracted from the messages to measure the execution and communication times of the objects and compute the percentage of the resources used by the objects during execution. The Profilers supply their measurements as feedback to the Resource Manager. During operation, the Profilers may detect overloaded or insufficient resources to provide the Quality of Service required by the user. The QoS can change either because of an explicit request by the user (for example, when the user desires a higher level of service) or implicitly while the application executes. In both cases, the Profiler reports the monitored change of the QoS parameters to the Resource Manager which can initiate negotiation with the user so that alternative QoS parameters can be selected. The Schedulers The Scheduler on each processor specifies an ordered list (schedule) for the method invocations on the objects on that processor, which defines how access to the CPU resources is granted. The schedule is based on the least-laxity scheduling algorithm. In least-laxity scheduling, the laxity of a task is defined as: Laxity = Deadline - Remaining_Computation_Time, where Deadline is the interval within which the task must be completed and Remaining_Computation_Time is the estimated remaining time to complete the multimedia task. The Scheduler calculates the Deadline and the Remaining_Computation_Time for each task, thus deriving the task laxity. The task with the least laxity is assigned the highest real-time priority, and tasks are then scheduled according to the real-time priorities assigned by the Scheduler. The Resource Manager The Resource Manager is implemented as a set of CORBA objects that are allocated to various processors across the distributed system. The Resource Manager objects are replicated for fault tolerance; logically, however, there is only a single logical copy of the Resource Manager in the system. All the replicas of the Resource Manager perform the same operations in the same order, and, therefore have the same state. The Resource Manager maintains a system profile that includes the physical configu- ration of the system (various resources along with their specific characteristics) and the multimedia objects running on the processors. As new requests are introduced, the Resource Manager determines whether it can satisfy those requests, by considering the available resources and the other multimedia applications running in the system. To make accurate decisions, the Resource Manager uses current system information, obtained from the Profilers, that increase the likelihood of meeting the QoS requirements specified by the user. For example, if a service requested by the user is available on more than one processor, the 12 Kalogeraki, Melliar-Smith & Moser Resource Manager selects the service from the most appropriate processor, e.g., the least- loaded processor or the processor located closest to the sender. The Resource Manager translates the QoS properties specified by the user into application QoS parameters and then allocates the necessary resources at the nodes along the path between the sender and the receiver. When insufficient resources remain to provide the required Quality of Service, the Resource Manager gradually degrades the Quality of Service for certain multimedia applications. The applications chosen are the ones with the least importance to the system, as defined by the user or determined by the Resource Manager. Alternatively, the Resource Manager attempts to reallocate the multimedia objects dynamically by migrating them to other processors. This reallocation may free some computing resources and enable the remaining objects to operate. Dynamic reallocation may also be required if a processor or other resource is lost because of a fault. If the quality of the multimedia applications continues to deteriorate, the Resource Manager can drop the least important multimedia applications so that the remaining applications can be accommodated at their desired level of service. IMPLEMENTATION AND EXPERIMENTAL RESULTS Prototype Implementation The platform for our implementation and experiments consisted of six 167 MHz Sun UltraSPARCs running Solaris 2.5.1 with the VisiBroker 3.3 ORB over 100 Mbit/s Ethernet. For the implementation, we used three Supplier objects, two of which transmit live images captured from different cameras, while the third reads a video clip stored in a file. The Supplier objects are located on the processors equipped with the cameras, while the third Supplier object is located on a different processor. Each Supplier object transmits its data stream to a Coordinator object located on a different processor. The Coordinator waits until it receives all of the data streams sent by the Supplier and merges them into a single stream, which it then transmits to the Consumer objects. The three Consumers receive data streams from the Coordinator and display each of the individual flows within the data stream on a separate display. Figure 6 shows the multimedia application at run-time. The implementation uses the XIL Imaging Library for image processing and compres- sion. XIL provides an object-oriented architecture and supplies a rich set of basic image processing functions that serve as building blocks for developing complex image processing applications. The implementation also uses the SunVideo subsystem, a real-time video capture and compression subsystem for Sun SPARCstations. The SunVideo subsystem consists of a SunVideo card, which is a digital video card, and supporting software, which captures, digitizes and compresses unmodulated NTSC and PAL video signals from video sources. MPEG-1 video coding is used for image data compression. The compressed video streams are transmitted over the network, stored on disk, and decompressed and displayed in a window on a workstation. Performance Measurements In our experiments we measured the end-to-end delay experienced by the video frames  Managing Real-Time Distributed Multimedia Applications 13 Figure 6: Multimedia application at run-time i.e., the delay between the time a video frame is captured from the camera at a Supplier, until the time it is transferred to a Consumer and displayed to the user. Of particular interest was the jitter associated with the random delays of the individual frames. Ideally, frames should be displayed continuously with a fixed frame rate. Typically, the jitter is eliminated by employing a buffer at the receiver (Stone et al., 1995). For example, if the receiver knows a priori the maximum possible end-to-end delay experienced by a video frame, it can buffer the first frame for this maximum time before displaying it. In our framework, the end-to-end delay experienced by the video frames depends on the following factors: (1) the time required for the Suppliers to capture the frames from the camera devices and compress them into a compressed frame sequence, (2) the time to transmit the compressed frame sequence from the Suppliers to the Coordinator, (3) the time required for the Coordinator to collect the compressed frame sequences from the individual Suppliers and combine them into a single stream, (4) the time to transmit the single stream from the Coordinator to the Consumers, and (5) the time required for the Consumers to separate the compressed frame sequences from the different Suppliers and decompress them for display. To determine the end-to-end delay, we assumed that the compression/decompression time of frames of the same size is approximately the same; thus, the end-to-end delay is mainly a function of the delay in the transmission of compressed frame sequences from the Suppliers to the Consumers and the delays in the collection of compressed frame sequences from different sources. Our measurements indicate that the frames are captured and displayed at the same rate at both the Suppliers and the Consumers, as the introduction of the Coordinator did not result in any irregularity in the compressed frame sequence transmissions and did not introduce any additional delay in the transmissions. Figure 7 shows the delay in the transmission of frames as a function of time, with the load on the processor increasing over time. As the load on the processor increases, the delay becomes larger and more variable. System jitter refers to the variable delays arising within the end-system, and is generally caused by the varying system load and the compression/decompression load. Network jitter 14 Kalogeraki, Melliar-Smith & Moser Figure 7: Delay (in ms) for successive frames as the load on the processor is increased Figure 8: Jitter as a function of processor load refers to the varying delays the stream packets experience on their way from the sender to the receiver, and is introduced by buffering at the intermediate nodes. For our application, we measured both the system jitter and the network jitter. The jitter mainly depends on the load on the processors at which the Suppliers and the Consumers are located. To demonstrate the effect of the processor load on the jitter, we introduced a random increase in the load of the processor at which the Supplier was located and the frames were captured. We measured the jitter when both a single Supplier and two Suppliers were used to transmit live images to the Consumer. Figure 8 shows that the jitter is larger for a single Supplier than for two Suppliers and that it increases unacceptably when the load on the processor is increased above 0.5.  Managing Real-Time Distributed Multimedia Applications 15 CONCLUSION Distributed object computing is becoming a popular paradigm for next-generation multimedia technologies. Several efforts have demonstrated that the CORBA provides a powerful platform for developing distributed multimedia applications. By leveraging the flexibility, portability and interoperability that CORBA provides, we can build real-time distributed multimedia applications more easily. We have designed a framework for managing real-time distributed multimedia appli- cations based on CORBA. The multimedia components of the framework consist of Suppliers that produce streams of multimedia data, a Coordinator that receives multimedia streams generated by the individual Suppliers and combines them into a single stream, and Consumers that receive the single stream of multimedia data and separate the flows within the stream to be viewed or played individually. The resource management components of the framework consist of Profilers that monitor the usage of the resources and the behavior of the application objects, Schedulers that schedule the tasks of the multimedia objects, and a Resource Manager that allocates the multimedia objects to the processors, sharing the resources efficiently and adapting the allocations over changing processing and network conditions. REFERENCES Alfano, M., & Sigle, R. (1996). Controlling QoS in a collaborative multimedia environment. Proceedings of the Fifth IEEE International Symposium on High Performance Distributed Computing, 340-347 Syracuse, NY:IEEE Computer Society. Aurrecoechea, C., & Campbell, A. T., & Hauw, L. (1998). A survey of QoS architectures. Multimedia Systems, 6(3), 138-151. Biersack, E., & Geyer, W. (1999). Synchronized delivery and playout of distributed stored multimedia streams. Journal of Multimedia Systems, 7, 70-90. Hong, J. W. K., & Kim, J. S., & Park, J. T. (1999). A CORBA-based quality of service management framework for distributed multimedia services and applications. IEEE Network, 13(2), 70-79. Kalogeraki, V., & Moser, L. E., & Melliar-Smith, P. M. (1999). Using multiple feedback loops for object profiling, scheduling and migration in soft real-time distributed object systems. Proceedings of the 2nd IEEE International Symposium on Object-Oriented Real-Time Distributed Computing, 291-300 Saint Malo, France:IEEE Computer Society. Kalogeraki, V., & Gunopulos, D. (2000). Managing multimedia streams in distributed environments using CORBA. Sixth International Workshop on Multimedia Informa- tion Systems, Chicago, IL. McGrath, D., & Chapman, M. (1997). A CORBA framework for multimedia streams. Proceedings of TINA’97 - Global Convergence of Telecommunications and Distrib- uted Object Computing, 239-243 Santiago, Chile:IEEE Computer Society. Mungee, S., & Surendran, N., & Schmidt, D. (1999). The design and performance of a CORBA audio/video streaming service. Proceedings of the 32nd Annual IEEE Hawaii International Conference on Systems Sciences, 14, Maui, HA: IEEE Computer Society. Nahrstedt, K., & Steinmetz, R. (1995). Resource management in networked multimedia systems. Computer, 28(5), 52-63. 16 Kalogeraki, Melliar-Smith & Moser Object Management Group, Inc. (1997). Control and Management of Audio/Video Streams Specification, 1.0. Object Management Group, Inc. (1999). The Common Object Request Broker: Architecture and Specification, 2.3.1. Rajkumar, R., & Juvva, K., & Molano, A., & Oikawa, S. (1998). Resource kernels: a resource-centric approach to real-time and multimedia systems. Multimedia Comput- ing and Networking, 150-164 San Jose, CA:SPIE-International Society for Optical Engineering. Stone, D. L., & Jeffray, K. (1995). An empirical study of delay jitter management policies. Journal of Multimedia Systems, 2(6), 267-279. Szentivanyi, G., & Kourzanov, P. (1999). A generic, distributed and scalable multimedia information management framework using CORBA. Proceedings of the 32nd Annual IEEE Hawaii International Conference on Systems Sciences, 15 Maui, HA:IEEE Computer Society. Le Tien, D., & Villin, O., & Bac, C. (1999). Resource managers for QoS in CORBA. Proceedings of the 2nd IEEE International Symposium on Object-Oriented Real- Time Distributed Computing, 213-222 Saint Malo, France:IEEE Computer Society. Vogel, A., & Kerherve, B., & Bochmann, G. V., & Gecsei, J. (1995). Distributed multimedia applications and quality of service: A survey. IEEE Multimedia, 2(2), 10-19. Waddington, D. G., & Coulson, G. (1997). A distributed multimedia component architec- ture. Proceedings of the First International Enterprise Distributed Object Computing Workshop, 334-345 Gold Coast, Queensland, Australia: IEEE Computer Society.