An Auto-Adjustment Video Mechanism for Steadily Monitoring of Remote Laboratory

—This work presents an auto-adaptable video streaming Web-based system, enabling on-line simultaneously monitoring of multiple instruments of remote experiment. The system is capability of not only handling multiple concurrent stream processes, but also automatically tuning encoding parameters of the running video streaming processes once overload so that the whole system can always keep in a smooth and steady circumstance.


INTRODUCTION
Remote instrument control has played an important role in industry and distance learning since it provides users flexible way to operate and learn instrument control at any time and from any location [1][2][3]. In order to let users have more realistic feeling of the current conditions at operating the remote instruments, the best way is to provide the users with not only a virtual control panel, but also a live (real-time) video capturing of the real panel of instruments [4][5][6]. Thus to observe the variations of real panel of each instrument, each instrument should be equipped with a digital camera. However, according to our previous work [6], monitoring of multiple instruments certainly taxes on significant system resources and loading since concurrent video stream processes have to run at the system. Thus, to keep the system loading within rational scope, this work presents a video streaming system with autoadaptable capability. By continuously measuring the system loading, the system adopts proper control mechanism and is able to dynamically tune the encoding parameter of the running streaming processes in order to keep it to work steadily all the time.
next section briefly describes the design architecture while Section III demonstrates our prototype. The testing experiments of the system are reported in Section IV. Conclusions are given in Section V.
II. PROPOSED DESIGN ARCHITECTURE The proposed software structure, shown in Fig. 1, comprises two layers: Web Application and Video Stream Component. The technologies and methodology of these two layers are described in detail as follows:

A. Video Stream Component
The 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 across all streams. The drawback is that bandwidth requirement of the encoded content can not be predicted. In a CBR mode, an output bit rate is required to specify. Accordingly, the encoding 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. Therefore, the bandwidth requirement of the encoded content can be predicted.
The sequential procedures inside each streaming process are to capture an instrument video, encode it with its own profile (e.g. encoder, frame rate, frame size), and then deliver it through network protocol, such as Real-Time Transport Protocol (RTP) or HTTP.
This Video Stream Component (i.e. Microsoft COM) is developed based on the Microsoft Windows Media Encoder Software Development Kit (SDK) which is a mul-timedia framework for media creation and distribution within Microsoft Windows [7]. The SDK provides useful API to facilitate encoding and delivering video media. Besides, since the SDK supports HTTP to deliver the video stream, HTTP is used as the protocol to transmit the video stream.

B. Web Application
This part consists of two main modules: Auto-Adaptable Mechanism (AAM) and Video Stream Control (VSC).
The AAM, which continuously measures the system loading (e.g. bandwidth, CPU and memory consumption) where measuring interval is three seconds herein, is responsible for keeping system loading to meet the predetermined overload criteria arranged by the administrator. The overloading criteria include the upper bound (threshold) of bandwidth consumption and CPU utilization and memory space. Once detecting one of their measured value exceed its upper bound more than the specified times (e.g. ten times herein), we define that such condition is overload happened. Afterward AAM will automatically adjust encoding parameters (e.g. frame size and frame rate) of the streaming processes via VSC in iterative way so that the system loading will eventually meet the predetermined criteria. In other words, once overload, the streaming processes will be adjusted one by one in a given priority sequences, which is also pre-ranked by the administrator, till the loading (e.g. CPU utilization) drops to its desired range. Currently, two encoding parameters, frame size and frame rate, are available for adjustment. Frame sizes is varied in the range [640x480, 320x240, 160x120] while frame rates is varied in the range [30, 25, 20, 15, 10].
The VSC aims at offering the system administrator to control and manage live video services (e.g. launching or stopping a video stream), depending on experimental requirements. For example, the administrator can enlarge the frame size or upgrade video quality for a clearer view of an instrument display panel. However, once overload detected, the VSC will degrade the frame rate (or frame size) of the first priority stream (e.g. frame rate from 30 to 25). If still overload, this downgrading procedure will repeat till the adjusted frame rate of the first priority stream process has reached bottom line (i.e. 10). However, if overload still being detected, the system will switch to the second priority stream process to degrade its frame rate once again till the frame rate has reached bottom line. Such procedures are employed iteratively on all streaming processes until the system loading is under the predetermined criteria setting. However, if overload still rises after the frame rate of all streaming process have reached bottom line, the AAM then switch to degrade the frame size of the streaming processes in accordance with the same procedure above till meeting with criteria requirements.
Likewise, if frame rate is specified as the autoadaptable parameter, the mechanism will first degrade frame rate from 640x480, 320x240 to 160x120 iteratively instead of degrading frame size first.
III. PROTOTYPE Currently, our prototype consists of one Web server and four USB webcams. After an authorized administrator  and encoding profile setup (bottom right) logs into the system successfully, one administrative page, shown in Fig. 2, reveals the setting for the system loading criteria which have to be settled before streaming processing running. In this figure, the priorities for these video devices are set from 1st to 4th; the frame size is selected as the auto-adjusting encoding parameter. The upper bounds of CPU and bandwidth consumption are settled in 30% while that of memory consumption is 60%. After finishing criteria setting, another administrative page, shown in upper-left page in Figure 3, will list all attached video devices for managing the video services, allowing launching or stopping a stream of webcam, looking the statistics of a live stream, and previewing a stream. In an attempt to launch a video stream associated to an instrument, the encoding profile (e.g. CBR or VBR mode) has to be set. As shown in bottom-right page in Figure 3, 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. This quality level supported in SDK is used to represent the quality of viewing a video.
IV. SYSTEM EXPERIMENT To evaluate the system feasibility and its Auto-Adaptable Mechanism, some experiments have been tested. Among these investigations, two different encoding modes, CBR and VBR, are adopted in order to individually analyze their impacts. In these experiments, the upper bounds of CPU and bandwidth consumption are  settled in 30% while that of memory consumption is 60%. In this case, frame rate is specified as the auto-adaptable parameter.

A. In VBR Mode
In this mode, four video streaming are launched sequentially, all of whose frame size and quality level are set 640x480 and 60 respectively. Besides, each streaming delivers video to two viewers to evaluate their bandwidth. Figure 4 manifests the certain duration of the system performance pertaining to CPU, memory (RAM) and bandwidth consumption representing in red, blue and gray line respectively. The Y-Axis title is consumption ranging from 0 to 100 % while the X-Axis title is the duration of monitoring the loading since system launching. The experimental result reveals that the number of activated processes has less impact on bandwidth and memory consumption comparing to CPU. However, while triggering auto-adaptable mechanism, CPU utilization instantly drops below the pre-determined upper bound (30%). In fact, the AAM has degraded the frame size of the first priority process from 640x480 to 160x120 and that of the second priority one from 640x 480 to 320x240.
Notably, the second of launching a video stream will cause a CPU utilization pulse, resulting in that there are several peak values of CPU utilization during the phase of launching the four processes in Figure 4. However, the CPU utilization will trend toward stably after a while.

B. In CBR Mode
In this mode, the testing environment is the same to the previous experiment except that output bit rate of CBR mode is settled in 1024 Kbps. Figure 5 also exhibits that the number of activated processes has much more impact on CPU utilization. While triggering auto-adaptable mechanism, CPU utilization also instantly drops below 30%. In fact, the AAM has only degraded the frame size of the first priority process from 640x480 to 160x120. However, the trend of Figure 4 varies more dramatically, comparing to Figure 5, since keeping consistent highest quality of all streams will heavily consume CPU computing. The CPU usage of four concurrent processes already reaches around 70% for the VBR quality level of 60 while around 40% for CBR with 1024Kbps output bit rate.
V. CONCLUSION This paper presents an auto-adaptable streaming system that handles multiple concurrent streaming processes and enables clients to view live video of their interested instruments. Based on continuously measuring the system's loading, the encoding parameters of the streaming processes are able to automatically be tuned in an iterative way in order to restrain system from overload. Based on the proposed two-layer architecture, it becomes easily and efficiently to achieve this aim.