Manageable and Extensible Video Streaming Systems for On-Line Monitoring of Remote Laboratory Experiments

—To enable clients to view real-time video of the involved instruments during a remote experiment, two real-time video streaming systems are devised. One is for the remote experiments which instruments locate in one geographic spot and the other is for those which instruments scatter over different places. By means of running concurrent streaming processes at a server, multiple instruments can be monitored simultaneously by different clients. The proposed systems possess excellent extensibility, that is, the systems can easily add new digital cameras for instruments without modifying any software. Also they are well-manageable, meaning that an administrator can conveniently adjust the quality of the real-time video depending on system load and visual requirements. Finally, some evaluation concerning CPU utilization and bandwidth consumption of the systems have been evaluated to verify the effectiveness of the proposed solutions.

Abstract-To enable clients to view real-time video of the involved instruments during a remote experiment, two realtime video streaming systems are devised. One is for the remote experiments which instruments locate in one geographic spot and the other is for those which instruments scatter over different places. By means of running concurrent streaming processes at a server, multiple instruments can be monitored simultaneously by different clients. The proposed systems possess excellent extensibility, that is, the systems can easily add new digital cameras for instruments without modifying any software. Also they are wellmanageable, meaning that an administrator can conveniently adjust the quality of the real-time video depending on system load and visual requirements. Finally, some evaluation concerning CPU utilization and bandwidth consumption of the systems have been evaluated to verify the effectiveness of the proposed solutions.
Index Terms-COM Component; Electronic Instrumentation; .NET Remoting; Remote Control; Video Streaming.
The applications of remote laboratory experiments play an important role in distance learning since it can provide students to learn instrument control and operation in a guided or self-explanatory way. Engineers also have chances to test new electronic prototypes or products at distance for verifying the compliance to parameters regulated by standards and norms.
The majority of remote laboratory experiments published so far in the literature focus on describing specific experiment setups, the scenario of system design, and the lifelike user interface of a real instrument. However, in order to let users have better realistic feeling and more consciousness of the current conditions of instruments, the best way is showing a live video of the real display panel of instruments. In contrast to other tools that send data and plot results in a scope-like chart using graphic resources at the client side, the real-time video is a powerful auxiliary tool to give users better percept of the current experimen-tal status and operation of instruments as if they are in front of the instruments.
A handful of works of monitoring remote instrumentation with live video have been presented. Ko et al presented a Web-based virtual laboratory on an oscilloscope experiment, using only one real-time video capturing of the actual oscilloscope display [1]. A Web-based virtual laboratory on radiofrequency (RF) and baseband video measurement using two real-time videos which individually capture the involved two instruments was also proposed [2].
Ranaldo presented a real-time video system, enabling clients to monitor the instruments of the remote laboratory distributed on a geographical network [3]. He used an instrument-control server equipped with a USB webcam which only delivers one video stream for an instrument at a time. Thus, the server, which can be regarded as the streaming server, is also in charge of encoding and streaming processes. There is a central server acting as a dispatcher responsible for redirecting encoded video content to the clients. However, to monitor more instruments under this structure, more streaming servers are required in order to capture more instrumental videos. To avoid this problem, Ranaldo further used an off-the-shelf IP camera with built-in MPEG-4 encoding and streaming capability to replace the streaming server [4]. Consequently, the main benefit of this method is that clients can adjust the characteristics of video streams according to current available bandwidth, since the used IP camera provides the capability of adjustment. This paper presents a video streaming solution for monitoring remote experiments that facilitate remote clients to better understand real instrumental status or experimental activities. Although we also adopt a computer as a streaming server as Ranaldo's first method, noticeably, our proposed design allows the server to be able to handle multiple concurrent encoding and streaming processes and each stream can have its distinguished video characteristics, such as video codec, frame rate, video size. Thus, multiple instruments can be monitored simultaneously by remote clients as long as the corresponding digital cameras are connected with the server. The proposed solution possesses excellent extensibility, that is, it can easily add new video devices without modifying any software. Also the live video are easily controlled and managed by an administrator in accordance with system load and visual requirements.
Based on the types of applied environments, two systems using the video streaming solution are individually developed. One is for the remote experiments whose appa-MANAGEABLE AND EXTENSIBLE VIDEO STREAMING SYSTEMS FOR ON-LINE MONITORING OF REMOTE LABORATORY EXPERIMENTS ratus centrally locate in one place. The other is for the remote experiments whose apparatus scatter over different places. Finally, after the two systems have been developed, some investigations concerning CPU utilization and bandwidth consumption have been manifested to evaluate the effectiveness and usability of the both systems. Next section will briefly introduce the two general types of remote laboratory experiments. Section III and IV will elaborate the proposed design of the both video stream systems. Also their advantages are stated and some typical GUIs are exhibited. The testing results of system performance are reported in section V and the conclusion is given in section VI.

II. REMOTE LABORATORY EXPERIMENT
In general, the involved instruments of the remote laboratory experiment are either concentrated in one geographic place or scattered over different places. For brief, herein we call the former as a central-location experiment (CLE) and the latter as a distributed-location experiment (DLE).
The works belonging to CLE mostly offers remote control via a portal server, as shown in Fig. 1 [1][2], [5][6][7][8][9][10][11][12][13]. The server also acts as a device controller accessing the physical devices (e.g. electronic instrumentation) via communication bus such as GPIB, USB, RS-232. Each prominent device should be equipped with one digital camera to exhibit the live video of real panel of its corresponding device.
The works belonging to DLE mostly consists of a portal server and several Instrument Control Servers (ICSs), as shown in Fig. 2 [14][15][16][17][18][19][20]. An ICS connecting with several nearby apparatuses can be regard as a branch-experiment platform. The portal server acts as a dispatcher that directs users to the desired platform to control instruments scattered over a wide area network. Thus, a user can remotely and transparently perform far distributed experiments on accessible instruments.
Most of the previous researches elaborate on investigating distributed technologies between the portal server and an ICS. These distributed technologies include Virtual Instrument Transfer Protocol [15], CORBA [16], Web Services [18] and Microsoft .NET Remoting [19].
For the two types, CLE and DLE, we individually develop one real-time video system, allowing users to monitor all the involved instruments of the experiment. The inner software designs and some interfaces of the two systems will be elaborated in the next two sections. The system for CLE is developed by means of the componentbased technology, Microsoft COM; while the one for DLE is based on the object-oriented distributed technology, Microsoft .NET Remoting.

A. The Software Structure
For video streaming on CLE, we propose the following software structure which comprises two elements, Video Stream Component and Web Application, as shown in Fig.  3. The former is a Microsoft COM component developed in Visual C++ while the latter is implemented by HTML, JavaScript, and ASP.NET. Under this structure, a computer simultaneously plays two roles: Portal Web Server and Video Control Server (VCS).   The Video Stream Component elaborates on constructing and distributing video streaming for electronic instrumentation. Thus there are several important works, mainly including detecting all connected video acquisition devices (e.g. USB camera, IP camera, or capture card), capturing video content from the devices, encoding (compressing) the video contents with a proper encoder (e.g., MPEG4, H. 263, and Window Media Video), and sending the compressed video content over the Internet.
To provide individual live video for each instrument, the system has to create individual streaming process for viewing each instrument. Also an extra data structure for MANAGEABLE AND EXTENSIBLE VIDEO STREAMING SYSTEMS FOR ON-LINE MONITORING OF REMOTE LABORATORY EXPERIMENTS each stream process is declared to store its own encoding profile, which characterizes a video stream. A encoding profile includes video device name, network protocol and port number, encoding mode, e.g. Constant Bit Rate (CBR) or Variable Bit Rate (VBR), encoder, frame size, frame rate, CBR output bit rate, and VBR quality level. Accordingly, each streaming process will capture an instrument video, encode it with its own profile, and then deliver it through used network protocol. This component is intentionally developed to providing a uniform interface (API) and call flow in order to facilitate the development of Web Application. As a Web application launches, it calls the Initialization() function, which detects and returns all video acquisition devices attached to the server. In the meantime, the individual memory space is dynamically allocated for each attached video device. To create a new stream process, calling Register() with the desired video acquisition device and desired encoding profile will register this new stream process with these provided information in the COM component. A corresponding handle of the stream process is then returned. A handle represents the registered information of a stream process, and is also used as an indicator for the consequent processing. Then, calling Operation() with the corresponding handle will launch the stream process to encode and deliver the stream over Internet. Calling Unregister() will stop a stream process and further release the corresponding registration and handle for recycling. As the application terminates, it calls Close(), which disconnects all video devices and frees the allocated memory space.
When several stream processes are employed in sequence, Register(), Operation(), and Unregister() functions are called iteratively. Accordingly, such design ensures each stream process can run independently. Moreover, it enables launching a new stream process dynamically for a new apparatus without modifying any code in Video Stream Component. The only thing to do is simply adding a new video device (i.e. plugging-in a USB webcam) for this new apparatus. Thus, the developed system is well-extensible.
In practical, we built the Video Stream Component with the Microsoft Windows Media Encoder Software Development Kit (SDK), a multimedia framework for media creation and distribution within Microsoft Windows [21]. The SDK provides useful API to facilitate encoding and delivering video media.
The Web Application contains two parts: Dispatch Module and Administration Module. The former directs a user to receive a streaming video of an instrument. The latter offers the system administrator to control and manage live video services depending on visual requirements and system load. For example, the administrator can enlarge the frame size or upgrade video quality for a clearer view of an instrument's display panel.

B. Operation and Some Interfaces
As shown in Fig. 4, the main administrative page lists all attached video devices for managing the video services. The remote administrator can launch or stop a streaming video, look the statistics of a live stream, and preview a stream. Before an attempt to launch a video stream associated to an instrument, an encoding profile (e.g. CBR or VBR mode) has to be set. Thus, when pressing a launching button, i.e., an gray arrow icon below the Change Status column in Fig. 4, a frame for setting the encoding profile pops up. As shown in Fig. 5, encoder, output bit rate, frame size, and frame rate need to be settled down in a CBR mode, while encoder, quality level ranging from 0 to 100, frame size, and frame rate need to be settled down in a VBR mode. The quality level supported in SDK is used to represent the quality of viewing a VBR video. Thus, all clients receiving video from the same stream will view the identical video (e.g. the same video quality and frame size). Fig. 6 illustrates the detailed status and the statistics of a live stream (e.g. current bit rate, the number of connected viewers, and their source IP addresses), and the video preview of an instrument.

A. The Software Structure
For DLE, we propose a software structure, which is also composed of two major parts: Video Stream Application and Web Application, as shown in Fig. 7. The former is a Microsoft .NET Application developed in Visual Studio .NET while the latter is implemented with HTML, JavaScript, and ASP.NET.
Differing with CLE, for applying to the distributed environment, Web Application is located in the Portal Web Server and one Video Stream Application is deployed in each Video Control Server (VCS). We adopted .NET Remoting as the distributed technique between Web Application and Video Stream Application. NET Remoting provides a powerful way for objects (or applications) located in different computers to communicate with each other. It also provides programmers with an object-oriented model for distributed computing as close as possible to programming with ordinary local objects. Remote objects are accessed through .NET channels, which are used to convey messages to and from remote objects. All called methods with their associated parameters are passed to remote objects and afterward the results of their execution return via these channels.
A .NET Remoting client and a .NET Remoting server are involved within the Web Application and Video Stream Application respectively for establishing a .NET channel. Via established .NET channels, the Web Application (.NET Remoting client) is able to access the objects provided by the remote Video Stream Applications (.NET Remoting servers).
The benefits of adopting .NET Remoting are: (1) The Web server can continuously interact with remote video objects deployed in VCSs, as if they were local objects. This feature hides the complexity of a VCS implementing a video object. (2) This solution possesses excellent extensibility, which can allow users to easily expand newly available VCSs and video devices. Actually, in our previous study [19], the .NET Remoting technique has revealed its superiority at developing distributed instrument control system.
A Video Stream Application consists of two classes. One class is aiming at constructing the .NET Remoting server on a VCS, intending for accepting connection from the .NET Remoting client. This class adopts a server acti-vation mode [22] and activates only one singleton object instance for every connected video device. A singleton video object instance in a VCS acts as a listener to handle all requests from the Web server. The other class, namely Video Stream Class, is aiming at wrapping the functions related to video streaming control on a VCS, intending for providing the interfaces for the remote Web Application accessing through .NET channel. Consequently, the digital cameras and video stream services in different VCSs spreading over the Internet/LAN can be uniformly utilized by the Web Application with calling these interfaces via .NET channels. Similarly, the inner implementation of this Class resembles the designs inside the Video Stream COM in CLE. That is, it offers the same functions (i.e. APIs): Initialization(), Register(), Operation(), Unregister(), and Close() for the development of Web Application and therefore ensures that each stream process on a VCS can run independently.
The Web Application also contains two parts: Dispatch Module and Administration Module. Differing from CLE, the former redirects the users to receive the streaming videos stemming from different VCSs. The latter allows the system administrator to transparently manage all scattered streaming video.
In order to establish .NET channel, a VCS has to launch its Video Stream Application first so that a .NET Remoting server can also be launched. Then the .NET Remoting client of the Web Application is able to connect the .NET Remoting server according to the VCS's IP address and its listening TCP port. At this moment, the establishment of a .NET channel between two sides is completed. Through the channel, the Web Application can further create a corresponding remote Video Stream object to utilize the provided APIs on that VCS.
Such distributed design is also well-extendable because the two reasons: (1) a new VCS can be integrated immediately into this system after installing the Video Stream Software ;(2) an existing VCS can dynamically launch a new live video for a new apparatus by simply adding a new video device (e.g. plugging-in a USB webcam). Both above two conditions can be achieved easily without modifying any code.

B. Operation And Some Interfaces
The main administrative Web page of our system is shown in Fig 8, connecting three VCSs, called VCS1, VCS2, and VCS3, via LAN. Each VCS equips with three USB webcams. However, the offered operations for the administrator in this system are identical to the prior CLE system, including starting or stopping a stream, looking the statistics of a live stream, and previewing a stream which can refer to Fig. 5 and Fig.6.
V. SYSTEM PERFORMANCE EVALUATION Multiple concurrent encoding and streaming processes running at a server certainly demand significant system resources and further impose this server loading. Note that under our proposed structures, such a streaming server precisely refers to the Web server in the CLE and a VCS in DLE, that is, where the streaming processes physically run. Thus, performance evaluations concerning CPU utilization and bandwidth consumption with respect to a streaming server are measured. For evaluation, a computer equipped with Intel Core Duo 1.66 GHz, 1GB RAM, and Window XP Pro, is acted as this streaming server. Among these investigations, two different encoding modes, CBR and VBR, are adopted in order to individually analyze their impacts. In a VBR mode, a desired quality level, ranging from 0 to 100, is required to specify. Under a given quality level, the output bit rate after encoding fluctuates depending on the complexity of the stream. That is, high motion will result in a high bit rate and slow motion will result in a lower bit rate. The benefit of quality-based VBR encoding is that the video quality is consistent among all streams. The drawback is that bandwidth requirement of the encoded content can not be known.
In a CBR mode, an output bit rate is required to specify. Accordingly, the video quality is not constant for content which complexity varies. The benefit of CBR encoding is that the output bit rate of the content is known before encoding, and thus the bandwidth requirement of the encoded content can be predicted in advance.

A. CPU Utilization:
In this evaluation, five different USB webcams are attached to the computer that launches five distinct stream processes. Additionally, our developed program is installed in the server to acquire CPU utilization mainly caused by these running processes.
The relationship between CPU utilization and the number of concurrent stream processes in CBR and VBR modes are shown in Fig 9 and Fig. 10, respectively. The concurrent stream processes is varied from 1 to 5. The output bit rate in the CBR mode is varied in the range [56,128,256,512,1024] Kbps while the quality level in the VBR mode is varied in the range [20,40,60,80,100]. The rest parameters are set as follows: • Frame Rate: 30 frames per second • Frame size: 320x240 • Encoder: Microsoft Media Video 9 Figure 9 manifests that the CPU utilization has positive correlation with the number of activated processes and the CBR output bit rate. Similarly, Figure 10 also exhibits that the CPU utilization is raised when the number of processes and the VBR quality level are increased. However, the trend of Fig. 10 varies more dramatically, comparing to Fig. 9, since keeping consistent highest quality of all streams will heavily consume CPU computing. For example, the CPU utilization of three concurrent processes already reaches almost 100% for the VBR quality level of 100.

B. Bandwidth Consumption:
This evaluation aims at observing the relationship between bandwidth consumption and the number of viewers under the condition where only one streaming process runs. The results of CBR and VBR modes are shown in Fig 11 and Fig. 12, respectively. The number of concurrent viewers is varied from 1 to 5. The output bit rate in the CBR mode, the quality level in the VBR mode, and the rest parameters are same to the previous evaluation. Figure 11 illustrates that bandwidth consumption is nearly proportional to the number of concurrent viewers and CBR output bit rate. Similarly, Figure 12 also exhibits that the bandwidth consumption is raised when the number of viewers and the VBR quality level are increased. However, the trend of Fig. 12 varies more dramatically, comparing to Fig. 11, since sustaining consistent highest quality of all streams will output the vast encoded bit rate, so that considerable bandwidth are required.     In addition, based on our tests, bandwidth requirement can be predicted when several stream processes using CBR mode are running concurrently. This is reasonable because these stream processes output constant bit rate. For example, if one streaming process encoded with the CBR mode output 30Kbps to 3 receivers (viewers), leading totally 90Kbps consumption, Such three streaming processes running simultaneously in a server will occupy nearly 270 Kbps bandwidth.
Since the video playing may be slightly delayed owing to the overhead of media handling and network transmission, the experiments regarding waiting time that a viewer has to wait before playing are also conducted herein. However, our testing results exhibits that network conditions, such as available bandwidth and congestion, have much more impact on viewer's waiting time, compared to the number of concurrent stream processes and the CBR output bit rate (or the VBR quality level).
VI. CONCLUSION This paper presents video streaming solutions for monitoring remote experiments to facilitate user's better understanding of real instrumental status or experimental activities. The proposed two systems deal with these remote experiments whose apparatus either locate in one place or scatter over different places.
Among them, noticeably, a streaming server is capable of running multiple concurrent streaming processes so that multiple instruments can be monitored simultaneously by multiple clients. Each stream has its own video characteristics so that the viewers requesting the same video stream will have the identical video, i.e. the same video quality. The proposed systems possess excellent extensibility since the systems can easily add new digital cameras for instruments without modifying any software. In addition, the live video services of both systems can be easily managed via administrative Web pages since our systems provide friendly interfaces with a transparent manner.
Finally, some evaluation concerning CPU utilization and bandwidth consumption have been conducted. Overall, the CPU utilization has positive correlation with the number of concurrent processes and CBR output bit rate (VBR quality level). The bandwidth consumption grows linearly with the number of concurrent viewers when using CBR mode. However, using VBR quality level has more dramatic influences on the bandwidth consumption. With respect to client's waiting time, these factors are negligible when compared to changeful network conditions.