Real-Time Multimedia Stream Data Processing in a Supercomputer Environment

The recent development of surveillance systems due to the threat of many attack sources, (including terrorists, organized and ordinary crime) has forced the municipal and state authorities to provide a wide range of security measures. The appropriate sensors are installed alongside the city streets and other public utilities providing a huge amount of incoming data, which needs to be processed and analyzed, either by a human or automatically by computer software.


Introduction
The recent development of surveillance systems due to the threat of many attack sources, (including terrorists, organized and ordinary crime) has forced the municipal and state authorities to provide a wide range of security measures. The appropriate sensors are installed alongside the city streets and other public utilities providing a huge amount of incoming data, which needs to be processed and analyzed, either by a human or automatically by computer software.
The computer centers with high-performance computers seem to be a natural solution for automatic mass multimedia processing, for which the computational power is a crucial factor. Moreover, they are usually located near metropolises, which in conjunction with their usual high-speed network connection, or even their direct placement in the network hubs makes them well prepared to receive huge data streams gathered by all surveillance sensors.
A prototype of such an approach being a real proof-of-concept was built and deployed in the Academic Computational Center and ETI faculty of Gdansk University of Technology in Poland. The proposed solution is realized as a hardware-software platform: KASKADA (Polish abbreviation: Context Analysis of Camera Data Streams for Alert Defining Applications). Its development was performed as a part of the MAYDAY EURO 2012 project. Apart from the platform, three pilot applications were developed: suspicious object and dangerous events recognition; endoscopy examination and disease identification, and intellectual property analysis and protection.
Though the proposed platform is a new idea, it can be compare to a the typical distributed/parallel programming frameworks. In comparison to the typical grid computing solutions: Globus (Foster & Kesselman, 1997) or Unicore (Breuer et al., 2004), it provides built in mechanisms for quality of service in the developed services and integrated approach to data stream computation management. For the more classical high performance computation architectures, like MPI with some task queue (eg. PBS), the platform provides service-oriented and real-time features, enabling easy development of the live multimedia streams services and user applications.
The proposed platform can be also compared to the typical distributed/parallel programming frameworks, like J2EE or .NET, however they are general purpose solutions www.intechopen.com Interactive Multimedia 290 and have only limited support for massive multimedia stream processing. An interesting platform was proposed in (Yu et al., 2009), in general it is also dedicated for multimedia real-time processing, however the mechanisms used are different, where the computations are concentrated in the database layer, while the KASKADA platform is focused in the middleware.

Challenges of the distributed multimedia processing
The typical supercomputer system is designed for the scientific-based simulation-like computations. It usually works over a distributed operating system under supervision of a batch-based queuing system, collecting requests as a list of computational tasks. Their processing is executed off-line without direct communication with the user. The multimedia processing, related to the video and audio surveillance systems, requires a real-time environment, supporting the continuous processing of live data streams, which brings new challenges for system and middleware software.
The first recognized requirement for the computational platform is to provide a proper concept of service management. We assume a service is a piece of functionality performing computations on an input multimedia stream, exposed by a well-defined interface to a user application. Thus, the platform needs to provide support for development, tests, and execution of such services. The proper tools for stream algorithm implementations, service creation and composition, are needed. Moreover, the platform needs to provide a standard service repository for conversions, decoding, encoding, and distribution of video and audio streams. Another important aspect is runtime management of services, where the proper mechanisms of resource allocation and monitoring need to be considered, we proposed the set of algorithms enabling the proper resource management with the optimization of fragmentation of the cluster .
Apart from a proper computational model, the proposed solution needs to guarantee an appropriate level of usability. The applications using the designed platform should provide a simple and clear user interface; thus, the platform itself should have a set of features enabling easy service development and composition. The solution should unify the processing model and be properly tuned for video and audio streams analysis.
Another problem needing to be solved is event management. We assume any working service performing stream analysis can reach a set of conditions, when the special actions need to be performed by other services or even outside the platform. Such an event can be asynchronously delivered using the message-passing mechanisms provided by the platform. It's worth noticing that the number of recognized incidents can burst drastically, causing a high computational and communicational load, which should be properly handled preserving all required constraints related to event filtering, message distributing and delivering.
The above requirements demand the usage of high-performance systems, in both computational and communicational areas. With respect to other aspects, like security or safety, we decided to build the platform based on the computational cluster located in the academic computer center. It consists of 1132 computation nodes, each containing two multicore processors, with 10896 of available cores. The nodes are interconnected by a high www.intechopen.com speed 20-40GB/s Infiniband network. The above configuration gives solid capabilities for parallel processed services, based on the parallel computations, analyzing hundreds of multimedia streams.
The specific characteristics of the performed analysis -real-time, security-related services rely directly on the dependability of the underlying platform -the dedicated platform needs to provide the ability to replicate the same computations, thus more accurate results can be obtained. Moreover, the resource allocation algorithms must provide the minimal, guaranteed level of resources so that the executed analysis is performed smoothly without delays and data traffic jams. We assumed (the typical) three types of resources to be managed directly by the platform: CPU load, indicating the complexity of the performed computations, memory depending mainly on the size of the problem context, which needs to be maintained during the analysis, and network bandwidth used to provide the flowing multimedia stream.
The increasing number of the analyzed services, depending directly on the incoming data, requires the platform to provide a flexible way to extend its computational and communicational capabilities. Thus the scalability of the proposed solution is a crucial factor for the final outcome of the executed services. The management procedures need to comply with the constraints and limitations given by the underlying hardware according to capability for the extension of its resources. Moreover, even for a single node the increasing utilization of the resources (cores, memory) used by the executed services needs to conform with the speedup of their computations.
Finally, taking under consideration performance, dependability, and scalability of the proposed solution, the proper means for maintaining the required platform state have to be developed. The monitoring subsystem is responsible for measuring and control of the cluster nodes and executed services. In case of abuse, such a component needs to be properly handled, the service needs to be stopped and the node isolated from the cluster. Moreover the monitor provides the external API for tracing the above measurements by the utility applications, so as to be able to react flexibly to the occurring problems. Fig. 1 presents a layered processing model for multimedia processing. The whole platform is deployed in the cluster environment -system infrastructure including a Linux operating system, computation nodes and the network. On the other side, it serves as a middleware for user applications, which are directly responsible for the interactions with the users (Krawczyk & Proficz, 2010b).

Multimedia processing model
Apart from the applications and the infrastructure, the model consists of the following four layers: (1) complex services, (2) simple services, (3) computational tasks, and (4) processes. The top layer manages the complex services exposed directly to the user applications, which are working according to defined scenarios of simple services included in the underlying layer. Figure 2 presents an MSP-ML example of a complex service scenario being a part of a videosurveillance system supporting the monitoring of entrances, with automatic comparison of the amount of people passing the gates; generating an alert when any gate is overcrowded,

www.intechopen.com
Interactive Multimedia 292 version for 2 gates. Two cameras are used capturing video streams and implementations of the following algorithms: decoder -unpacking encoded video frames, background remover -the algorithm detecting moving objects in the video stream and removing the background, human detector -the algorithm detecting a human silhouette in the incoming images, event counter -comparing the number of messages with detected events describing incoming people and signaling large imbalance between them.  simple service (1) -decoding video stream from gate 1  simple service (2) -background exclusion on the stream received from task #1  simple service (3) -human detection on the stream received from task #2  simple service (4) -decoding video stream from gate 2  simple service (5) -background exclusion on the stream received from task #4  simple service (6) -human detection on the stream received from task #5  simple service (7) -counting and comparison of events from tasks: 4 and 6,with parameters indicating alert (event) if the number of passing people on any gate is 20% greater than average The complex services layer is responsible for execution of scenarios consisting of complex and/or simple services according to the following steps: 1. Creation and validation of a service scenario. In the preliminary phase of service execution, the platform creates a sequence of simple services used by the particular steps of the scenario. It consists of the vertices representing the services and directed edges indicating data flow. We assume that such graphs are acyclic -no feedback is allowed.

293
The service descriptions are retrieved from the repository of scenarios and their inputoutput data types correctness id validated, see figure 3 (a). 2. Algorithms' selection and required resource estimation. In this step, the service scenario is converted into a new data flow graph including the computational tasks as vertices and directed edges representing data streams' flow, see figure 3 (b). This transformation is dependent on the requested quality parameters, which can have influence on the tasks algorithm selection as well as on the input data choice, e.g. camera resolution. si -simple service, ti -computation task, ni -computation node, pi -process/thread Fig. 3. Phases of preparation to service scenario execution: (a) simple services; (b) task graph; (c) tasks' assignment to the computation nodes; (d) tasks running as processes and threads.
3. Task assignment to the cluster nodes. In this step, the vertices of the data flow graph, i.e. computational tasks (derived from the simple services) are assigned to the concrete cluster nodes, see figure 3 (c). We would like to emphasize that the tasks need to be executed parallel or concurrently, satisfying requirement for on-line processing and is more similar to a variable sized bin packing problem. The optimized criteria can be as follow: minimizing the number of partially used nodes (defragmentation), minimizing total network load, or the total delay of the scenario processing (Krawczyk & Proficz, 2010a). 4. Scenario startup. In this step, the computational tasks of the respective simple services are started up on the cluster nodes according to the given assignment. The task identifiers are generated and distributed. The proper data streams are assigned to the tasks and the communication is initialized. Each task after initiation consists of one or more processes/threads, whose execution is managed directly by the operating system installed on the cluster nodes, see figure 3 (d). 5. Scenario monitoring. During the scenario execution, the platform will monitor the running tasks and evaluate the following parameters: processor load, memory usage, multimedia, event and plain data streams' flow. The evaluation procedures are used for continuous collecting and verification of quality related meta-data describing the particular services. 6. Scenario termination. In the last step, the platform is responsible for the correct termination of all computational tasks executed with the scenario. This means that, all related processes and threads are finished, the associated resources are freed, the multimedia streams are closed, and the proper information messages are sent to the client.
The next layer of the proposed model, presented in figure 1 is involved in execution of the simple services, which are responsible for selection of the proper algorithm form alternative proposition according to the requested quality parameters. Moreover, the multimedia stream distribution to the computational tasks is established. For the sake of minimizing network load, the RTSP protocol with the multicast is used.
The next layer corresponds to the computational tasks, which are the implementation of the concrete stream analysis algorithms. They use the libraries of special functions such as cooperation with other components of the platform, including storage or an event server. It perceives the framework as a template, which already includes supporting objects used by the algorithm implementation, e.g. an image frame iterator for a video stream. This layer is responsible for task distribution, and requested resource allocation: nodes and processors. It also uses a typical launcher for these purposes, besides additional qualities of service policies, e.g. delays to the start of each task are considered.
The process/thread layer enables execution of the computational tasks. They can use typical mechanisms of concurrency and parallelism. The platform supports POSIX threads and other similar mechanisms provided by the underlying operating system.
The model described above was implemented in the KASKADA platform, all its layers are realized and their cooperation is managed by specialized servers. The description of the platform architecture is shown in section 6.
To create user application we build, we use a suitable application server cooperating with the KASKADA platform. The main part of the application is a specialized interface which allows to perform one or more of the possible user scenarios consisting of simple or complex services running on the KASKADA platform. We start with an idea of multimedia stream processing, for instance identification of wellknown objects or events. Then we can focus on the algorithm described in pseudo-code or other high level language, eg. flowchart. When that transition appears, we translate them to the real source code. It is compiled and linked into a computation task executable code.

Development environment for multimedia stream processing
Having the executable algorithm program we enrich it with the quality and parameters metadata to obtain a simple service. The platform provides automatic generation of the W S L D d e s c r i p t i o n o f t h i s s e r v i c e , w h i c h i n t u r n c a n b e u s e d t o b u i l d m o r e c o m p l e x structures. The special language MSP-ML was designed to express the service composition keeping characteristic stream-processing constraints.

Algorithms to computation tasks
The KASKADA platform supports execution of multimedia stream analysis algorithms as computation tasks. They can be able to receive an input stream to detect objects and events, and finally to generate the output stream. Moreover, the tasks can be composed in pipelines or even more complex structures, so that the results of one task can be used as an input of the others. For instance we can distinguish a task detecting faces in the monitored video stream, and then one recognizing specific properties of the face, and a final task checking the database of persons wanted by the police.
The KASKADA platform provides a dedicated framework supporting implementation of the analysis algorithms. Every algorithm, embedded in the KASKADA framework, can use a special API providing the platform functionality: multimedia encoding and decoding, intermediate results interchange, signaling the events, processing the input parameters, and stream synchronization. The algorithms are implemented in C++ and together with the framework create computation tasks (see Fig. 5) under the Linux operating system in the cluster environment. Multimedia streams captured by the cameras or microphones are received under the RTSP protocol, the framework decodes the flowing video frames or audio probes and forwards them as input data to the task. Additionally, it can use the metadata related to the received stream, eg. the currently processed frame timestamp, resolution or video frame rate, or the audio probing frequency.
Another interesting feature provided by the KASKADA framework is a mechanism managing input parameters. They are formatted according to the convention used in GNU GPL license software. The framework recognizes the parameters related to the streams, filters and interprets them, in order to reconfigure the implemented algorithm. The platform provides the methods for parameters' propagation through the platform layers, so they don't need to be distributed manually to the destination services or tasks.
From an input data distribution point of view any task can be executed in three different modes: off-line streaming from a file, off-line streaming from a streaming server, and on-line directly from the stream source (see Fig. 6 a-c). The first mode enables direct usage of archived streams using a network file system, that the processing can be even faster than the recording, eg. for video streams the processing frame rate is limited only by the CPU speed.
The streams transmitted in the off-line streaming server mode are provided in a very similar fashion to the live streaming, with the exception of the data source, which is located in the off-line archive. This approach supports the tests using the archived content, but within the constraints of the live streaming. The later mode is based on the direct connection to the streaming device, ie. a camera or a microphone enabling their real-time processing.
From the point of view of output data distribution, the algorithm execution and tests can be performed using archiving or streaming modes (see Fig. 6 d-e). In the first case the processed output stream is stored into the archive file, and in the latter the results are transmitted by a streaming server to the client. There is also the possibility to use a hybrid approach where the data are simultaneously stored in the archive and transmitted after some transformations to the users (see Fig. 6 f). The above algorithm input/output modes directly implies interaction modes with the services or even the whole platform. Thus we can distinguish the following interaction modes: 1. Real-time mode -when the multimedia streams are directly processed and the results are provided to the user. 2. Off-line mode -when the streams are read directly from the archive and the results are stored for the user. 3. Real-time simulator mode -when streams are read from the archive, but they are transmitted to the tasks just like from their original source, and the results are provided to the user -used for testing purposes.
Apart from the multimedia stream, any running algorithm can send the messages enclosing the detected objects or events it found during the processing. The KASKADA framework provides the message passing API, and the platform contains the mechanisms of their routing, delivering, and monitoring. Fig. 7 presents an example source code for sending the message, and the screenshot of the web browser with monitored messages containing the information about reported events. www.intechopen.com

Algorithm to service transformation
The implemented algorithm, after linking with the KASKADA framework libraries and its preliminary tests, can be used as a base for creation of a simple service, which can be offered as its remote access. From the point of view of a programmer, the service is an interface backed up by the task and accessible through the platform.
It is possible to implement a few alternative algorithms realizing the same service, but providing different levels of processing quality, ie. dependability, performance. On the other hand, there can exist an algorithm matching two, or even more, services providing their functionalities. Fig. 8 presents an example of such multiple relations between algorithms' implementation and services. The KASKADA platform stores algorithms' metadata, as well as providing the means to manage them. For this purpose an appropriate user interface was implemented including such functions as adding, removing and modification of the data: an algorithm's name, executable file path, input and quality parameters. An exemplary list of algorithms was presented in Fig. 9. Similarly to algorithms, the simple services are described by their metadata, including: a service name, the description, input and quality parameters. Additionally, the implemented algorithms realizing the suitable service can be easily point out by simple name selection from the list. Every selected algorithm can use the service input parameters passed during its execution, however their handling is optional.
The developer can start the service in two modes: by remote call or using a web browser. For testing/debugging purposes the latter one is more feasible, when she/he just needs to introduce the parameter values and click the "start" button. Both modes are provided automatically by the platform, just after the service definition. Fig. 10 presents the steps for service definition and execution. After successful initiation, the developer can check the result data stream and the events in the messages generated by the algorithm and logged in the special logs. The remote call of a simple service can be realized using HTTP/SOAP protocols. In such a case the programmer is responsible for a proper implementation of client being part of user application. To simplify this process, the KASKADA platform provides its own UDDI registry, where the services are described using always-updated documents in WSDL format.

Simple to complex service transformation
Similarly to a simple service solution, the complex services are accessible by a web browser or through the external interface based on SOAP/HTTP protocol. The choice also depends on the input and quality parameters, and accept the multimedia streams as an input. They aggregate simple services within execution scenarios. ie. in more complex structures, which extends their functionality. Fig. 11a presents an example of an execution scenario, discussed in section 3. The scenario can be described by XML language as a set of simple services and input/output data stream definitions, see Fig. 11b. The document is created by the developer using a typical text editor, or a specialized language: MSP-ML. Based on this we entered a GUI interface as the proper form as shown in Fig. 11c.
Every single service needs to have provided input and quality parameters, specific to its underlying algorithm. They can be introduced in two ways: forwarded from the complex service description, or fixed during the complex service definition. Using this approach, we achieve flexibility required for the service execution.

Execution environment for multimedia stream processing
We distinguish four domains of the platform management during service execution: (1) data, (2) computations, (3) communication, and (4) resources. Data as real-time streams of the incoming multimedia data either video or audio, need to be archived and distributed among computation tasks. Computation means the stream processing tasks, which are involved by instructions of program. Communication is understood as message exchange mechanisms enabling distribution of the events among service components and sending to the external client. Finally, the cluster resources are engaged in computations and constantly observed by the monitoring mechanisms, including checking and reacting on the inappropriate usage of the network, CPU and memory.

Data -Multimedia stream management
The multimedia data streams are generated by a geographically distributed set of video cameras and microphones. They need to be delivered to the computation center and preprocessed for further analysis. The number of streams, and their characteristics, demands the usage of a high bandwidth optic fiber network. Fig. 12 shows the view of the multimedia streams in the considered platform regarding the users, as well as the external applications using the platform functionality. The arriving data needs to be received, validated, and archived, due to additional offline analysis and legal concerns. The above operations are performed by the tasks controlled by the management server. The server can also cooperate directly with the stream sources. Preprocessing is used to unpack the stream data from its native protocol, usually RTSP, and forward it to the proper analysis tasks located on the computational nodes using an Infiniband network. The higher platform efficiency can be achieved by allocation of tasks with streams to more cluster nodes. A special set of the cluster's computational nodes is assigned to perform such tasks using the high performance network file system LUSTRE. Physically, the data is stored on a specific data server with high performance 500TB hard drives. The various algorithms exposed as services can consume incoming streams and produce messages (as events created during the analysis) as well as new output streams, which should be delivered to the user. See the next section for more details about the flow of events.
The information about produced output streams are sent back to the stream management server nodes and they are ready to be delivered to the selected users. It can be done by the user console module. The stream-related functionalities of the user console cover:  registration and testing of new multimedia (audio or video) streams,  configuring the meta-data of the stream, including codec, fps, width, height etc.,  archive configuration with individual settings of each stream,  creation (by upload or archive selection) of the test streams used for benchmarking and testing of the algorithms,  playing and replaying of the live or archived streams.

Communication -Event management
An application controlling the processing of the started service can receive the results of the predicted analysis by means of event processing. An event, as specified in section 1, is information generated by a task belonging to the service, which is potentially important for external applications or their users. Such information is expressed by a message transported in XML document format. The type of the message and its content are determined by the particular algorithm implemented by the task. It is not compulsory for the task to finish its work after creating and issuing an event; the multimedia streams can be processed continuously causing generation of many events for different situations detected in the streams during their processing. Such series of the events can be conceived as the events stream or the data stream (Olken & Gruenwald, 2008). The processing of such a data stream can be focused on the selected events, treating them independently, or as the sequence of events, where state-aware operations analyze one event after another. Fig. 13 shows the event processing idea in the KASKADA platform; starting from the event creation, through event handling and ending with the special message being passed to the specified destinations.
The tasks belonging to the service searching media streams, with respect to detection of special object and/or particular situations. The successful detection of such situations causes generation of an event containing information about its origin and processed media time, apart from data related to the particular event type. Then, each event is passed to an Event Handling Module through the message queue maintained by Apache ActiveMQ. The choice of ActiveMQ as the message queue provider is, among other things, determined by different technologies, C++ and JEE, being the runtime environments for the event processing flow elements. The Event Handling Module performs the operations during event processing, such as save, apply events, create and send message (see Fig. 13).
Operation: Saves the event in repository: each event incoming to the Event Handling Module is stored for administrative and safety purposes, using the Events Repository mechanisms. The storage structures associate the event with the data stream related to the service in order to enable later backtracking of the selected service results. Using the information about the service-starting details, preserved by the KASKADA platform, and the archive of media streams, it is possible for the particular event to reconstruct the conditions which led to such an event generation.
Operation: Applies filters to the event: the user console of the KASKADA platform supports a choice of filters applicable to the event processing. A filter can be applied to check if particular properties of the event fulfill criteria defined for that filter. The criteria for a filter can specify a service or XPath expression. If there is consistency between XML content of the event and the specified filter settings, the service and the expression, the event becomes active.
Operation: Sends the event message to the channels: the filter applied to the processed event contains one or more channels. A channel represents a final destination for the information about processed event. The XML message describing the active event is delivered to the recipients specified by details of each channel. The information contained in the channel details is determined by the channel type which represents the transport mechanism used by the particular channel. The currently-supported channel types are the e-mail type and the JMS compliant message queue system type. Nevertheless, the KASKADA platform is ready to support additional types, and also for implementing the transport mechanisms related to them. Fig. 13. Event processing idea in the KASKADA platform An Event Management Module is a part of the user console of the KASKADA platform; and, as other modules of the console, is designed to work with an end-user in an interactive mode. There are a few functionalities supported by the module (apart from the describedabove definition) and management of event filters. The module makes available a real-time monitoring of incoming events related to the particular service while it is still running. The console user can inspect the archived event streams, for example searching for particular circumstances. The module allows replaying the part of the archived media stream related to the selected event during its examination, adjusting the time frame of the played part if necessary.
Different types of destination channels open the KASKADA platform to the various technologies of implementation of the applications receiving the results of calculations of services. Apart from the technology, there are two typical scenarios of the interoperability of the user applications and the KASKADA platform. The scenarios can be described as follows:


The operator of an external, interactive, application starts a service through the application monitoring mechanisms. Then, the application processes incoming events and stops the service; for example after receiving a particular event, presenting the operator with the processing results. The above sequence applies to the processing of a selected part of the stream, as a result of a more general, continuous, analysis.  The advanced, distributed, application automatically starts a service with mechanisms contained in one of its components. The started service, without stopping its work, generates events which are delivered to another component of the same application, or even to another application. The scenario separates the management of a service execution from the pure event processing, allowing the application to be more flexible and modularized on a high level.

Computation -Service and task management
As was described in section 1, the complex services are executed as a set of simple services according to the describing scenario. The simple services are realized by the computation tasks, which in turn are represented by the processes and threads in the cluster environment (see Fig. 1 for comparison). The tasks need to be placed in a suitable computation node, according to the appropriate task schedule achieving the required computation time.
The typical problem of task scheduling is defined as assignment of a set of tasks into the set of computational nodes in an order to execute them in minimal time. It is proved, the above problem is NP-hard for the general case, and there exists a polynomial solution for task scheduling on two computational nodes (El-Rewini & Lewis, 1994).
The proposed architecture assumes that tasks are executed continuously, consuming and producing data streams. Each of them requires concrete computational power to realize the provided functionality. We assume that due to the character of multimedia stream processing, the tasks require real-time execution, and they cannot be queued and started with delay in the sequence one by one.
We propose a specific a task-to-nodes assignment strategy regarding the above constraints. The tasks could be assigned to the computational nodes, which are able to execute them directly. Otherwise, if there no such nodes exist in the cluster, the service scenario (scheduled tasks) is not executed, its execution is refused and signalized to the user. To minimize the occurrences of such cases the platform should optimize its selection using the criteria of minimizing the fragmentation.
In such a way the assignment strategy is quite similar to the well-known bin packing problem (BPP) (Garey & Johnson, 1979), especially its version with the variable bin sizes (VBPP) (Haouari & Serairi, 2009). Typical BPP minimizes the number of baskets (computational nodes in our case) used for packing a set of objects (tasks). The version with the basket variable sizes introduces additionally a finite set of basket types with different sizes. An exact algorithm for (V)BPP is NP-hard (Garey & Johnson, 1979).
In the proposed assignment strategy we can use as many baskets of possible type (size) as we need, but the number of each type is finite. Moreover, the optimisation goals are different, VBPP minimizes the number of used baskets and our startegy considers the number of partially used nodes.
The fragmentation factor indicates the number of nodes partially engaged in task processing. Fig. 14 shows a situation where a new heavy task cannot be assigned to any node, because all nodes (c 1 -c 4 ) offer less computation power than it is needed for the task t (Φ(t)=6). In (Krawczyk & Proficz, 2010a), we proposed a few heuristic algorithms to minimize the fragmentation what in turn enables execution of more tasks with high load, ie. Φ(t)=6 in the example. www.intechopen.com

Resources monitoring
In the case of the KASKADA platform we distinguish three kinds of resource characteristics: network bandwidth, memory size and CPU load. According to the assumptions described in the previous section, each computation task needs to have guaranteed the proper amount of the resources, and the tasks behaving incorrectly have to be deactivated and their service stopped. Moreover the monitoring information needs to be presented to the external client using either GUI or by the webservice interface.
The KASKADA platform monitor is responsible for the following functionality:  managing the services and tasks,  monitoring the current resources utilization,  informing the user about the tasks' errors and exceptions,  logging the information about the platform, services and tasks behavior,  checking the computational node states related to network connection and file system behavior. The KASKADA monitor consists of two functional components: computation monitor -the central component keeping the states of the services and their tasks and monitor daemon, running on every single cluster node, which cooperates directly with the tasks, gathering the information and executing orders from the computation monitor. Fig. 15 shows an example diagram of the scheduler and both monitor components when the user starts a service.

KASKADA -Architectural design and realization
6.1 Software architecture The proposed in section 3 processing model was implemented as the KASKADA platform. Fig. 16 presents the main classes to satisfy functional requirements. From the user's point of view the main goal of the platform is to provide the webservices based on SOA architecture. They will be responsible for execution of the complex service scenarios supported by simple services. The example sequential diagram of the scenario execution is presented in figure 17.
Both service types, i.e. simple and complex ones, are going to be deployed on the same JEE application server, we consider using a Tomcat web container for this purpose. They will utilize SOAP technologies over HTTP(S) protocol, in case of synchronous remote calls, and a queue system, i.e. ActiveMQ for asynchronous communication within JMS interface. The result return will be performed in separated objects (and components): Event Handler for messages and Dispatcher for multimedia streams. According to the assumed processing model, simple services manage the distribution of the input and output data streams among computational tasks. The object of classes Dispatcher and Scheduler support this functionality. Moreover, the responsibility of the Dispatcher object is the stream recording in the storage and sending them back to the client. The example sequential diagram of the simple service execution is presented in Fig. 18. Computational tasks -the executable code of the multimedia stream analysis algorithms embedded in the framework accomplish the appropriate computations. They receive the multimedia streams generated by a camera, microphone, or other device (e.g. medical equipment), make the required analysis and transformation and send an output data stream including discovered events to the proper components, mainly to Event Handler and Dispatcher, forwarding them through the service layers to the clients -a users or an external applications (see Fig. 19). During the algorithm implementation, the programmer can use software components provided by the computation cluster environment: POSIX threads and openMP library for shared memory processing and object serialization (supported by boost library) for object data exchange between the computational tasks. Almost all the above domain classes presented in Fig. 16 can be straightforwardly converted into the software components of the proposed platform. The only exception is the User Console component which aggregates Scheduler class as well as manages the other platform components including operations on the multimedia and other data streams (especially in off-line mode -using recorded data), security and service configuration and deployment (a service repository with the WSDL and UDDI support).
User console functionality is provided through a web interface and can be easily accessed with an Internet browser. For its development, we use JEE standard supported by an application server, i.e. a Tomcat web-container, including technologies: JSP and AJAX.

Hardware architecture
To execute computation tasks all software components should be deployed on the computer cluster. Fig. 20 presents the deployment diagram including hardware nodes with the assigned software components. The core of the platform is the cluster which consists of 672 two-processor (Intel) nodes connected by the fast Infiniband network, each processor has 8 cores, which gives in total 5376 cores. The stream managing sever is responsible for multimedia stream format and communication protocol conversion, enabling its usage by the computational tasks and receiving by the clients. It is especially important due to the large number of streams, and network load minimizing strategy: some cameras or other devices, do not support multicast data transmission, so it needs to be provided by the platform. The Dispatcher component is responsible for this functionality, as well as stream recording and archiving.
The process managing server is responsible for direct cooperation with the client software.
Here are deployed services and the User console component. It is prepared for serving a large number of webservices, the simple ones -which are easily mapped to the computational tasks -as well as the complex ones, executing the scenarios.
The messaging server supports the Event handler component. It enables receiving, analysis and former processing of the data (but not multimedia) streams containing discovered events. It cooperates with the process managing server where the event related services are deployed.
The data server is used for recorded data storage. We use high performance hard drives with 500TB capacity and the Lustre file system, the server is going to be connected to the cluster and other servers by the Infiniband network, for its low delay and high bandwidth.

Applications available in KASKADA platform
The KASKADA platform was heavily tested for two pilot applications, developed as a proof of concept of the proposed multimedia processing model: identification of dangerous objects and unusual situations (DOUS) occurring in multimedia streams coming from cameras located in different places, and medical recommender for endoscopy examinations (MREE) showing some disease changes in film taken during gastroscopy track. The former is used for automation of typical video and audio surveillance tasks, like dangerous person identification or left luggage detection. The latter helps medical staff to quickly find the possible lesions in the video recorded during endoscopy examinations. Quality characteristics are one of the most important features evaluating the whole platform behavior. During the platform analysis and design, we found out we need to focus on four key factors: performance, scalability, dependability and security. Performance is crucial for real-time processing, both processor speed and network bandwidth need to be examined, for the platform to work in the real environment. The scalability is another important factor, especially when large numbers of the input streams need to be archived, processed, and transmitted back to the customer. Moreover, even the high performance solutions can't provide the satisfactory results until they are dependable (the designed algorithms are correct and acceptable for various conditions), and finally the character of the processed streams, including surveillance and medical data, requires high security protecting access from unauthorized persons. The above applications, especially DOUS, can achieve the appropriate public security level using strategy illustrated in Fig

Conclusion
The KASKADA platform is designed to cooperate with external systems and applications. We decided to use a typical approach based on the SOA architecture with support for both synchronous and asynchronous communication, and implement a typical HTTP/SOAP protocol to start the exposed functionality, and message-passing queue system, supporting JMS and XMPP protocols to return the results of the long-lasting processing.
The platform is developed using agile development process principles, so the possible updates and new features can be added quite quickly, from one iteration to another, with release of a new version. The platform itself is flexible with easy and extensive configuration enabling quick adaptation to a new environment, or volume of the problem. With possible virtualization and cloud computing support.
The KASKADA platform is already developed and deployed in the Academic Computer Center of Gdansk University of Technology in Poland. The current development is focused on the quality tests related mostly to the performance and scalability characteristics. The whole project, including the proposed applications, is going to be finalized in 2012.
In the future we plan to continue development of new applications based on the currently available services, as well as new algorithms for the various multimedia processing problems, with a special focus on massive stream processing and various quality parameters, like dependability and security.

Acknowledgment
The work was realized as a part of MAYDAY EURO 2012 project, Operational Program Innovative Economy 2007-2013, Priority 2 "Infrastructure area R&D".