Some Remarks on Choosing Video Stream Encoding ...

Some Remarks on Choosing Video Stream Encoding for Remote Video Verification on Android Mobile Devices Dariusz Mrozek, Bartłomiej Buk Institute of Informatics Silesian University of Technology Gliwice, Poland [email protected]

Abstract— Video verification on mobile devices, such as cell phones and tablet PCs, allows users to remotely check what is happening in a particular place without the need to constantly monitor the site and record video from the camera. This requires appropriate stream encoding to be applied. Unfortunately, existing encoding standards, widely used in video monitoring, have several drawbacks. In the paper, we show some remarks on choosing video stream encoding for video verification on Android-based mobile devices. Results of performed tests on bandwidth usage have shown that encoding based on passing static frames in JPEG format translates very well into an environment where the camera’s resolution is often higher than the mobile device screen. Keywords—video monitoring, video surveillance, video verification, mobile devices, mobile phones, video stream encoding, Android

I.

INTRODUCTION

In CCTV (Closed-Circuit Television) the concept of video verification is that of a mechanism that allows security personnel to verify, whether an alarm signal is a false positive. Most commonly this means that a burglar alarm has some cameras installed, the cameras observe the areas protected by the alarm system’s sensors, and whenever there is an alarm the security staff is notified. But instead of rushing to the sensor that was triggered, they first log into the cameras to check whether or not they can see any reason for the alarm. Only after this process of verification, and provided there is a reason for the alarm, the security group heads for the target area. This is video verification defined in terms of Closed-Circuit Television. Quite a simple idea, that when viewed as a more general approach gets even simpler. Broadly speaking video verification is a process in which a person can log into a workstation that will provide some video footage. By viewing that footage this person is then able to verify or check some fact or place. The need to verify the place can be triggered by an external signal, e.g. an alarm, or may be just done on a whim. Video verification triggered by a signal usually provides some sort of recording from the time of the trigger, while video verification without a trigger has to provide only the current image. In the scope of this paper only the video verification

Bożena Małysiak-Mrozek Institute of Informatics, IBM Competence Center Silesian University of Technology Gliwice, Poland [email protected]

without trigger, and therefore without recording capabilities will be discussed. Remote video verification simply denotes that the mechanism for video verification is accessible not only from a designated workstation, but there is a mechanism provided that allows the user to log into the system, e.g. using a mobile phone, in almost any situation. It is also essential to distinguish the concepts of video verification and video monitoring. Video monitoring usually provides a live image and ability to record everything. And actually, there is nothing a video verification system can do that a properly designed video monitoring system could not. However, setting up a whole monitoring system in some cases may be a bit excessive. The complexity of a properly designed video monitoring system is several orders of magnitude more complex than that of a video verification system; in some cases it is an unnecessary complexity. Several papers, such as those mentioned below, discuss the problem of building simple or complex remote-accessible surveillance systems, and transmitting video stream for mobile devices through the Internet or GSM network. In [1] AbuLebdeh et al. present the system architecture dedicated for mobile video surveillance applications applying the 3GPP 4G Evolved Packet Core (EPC) allowing development and management of QoS-enabled mobile video surveillance applications. In [2] Chen et al. propose a real time video surveillance system consisting of many low cost sensors and a few wireless video cameras in order to reduce the number of cameras needed in monitoring the target area. In [3] Marais and Hancke show a low cost video monitor store and forward device with motion detection and remote control capabilities using low cost CMOS cameras and transmission over the GSM/GPRS network. The HASec system described in [4] uses mobile devices to operate and control motion detectors and video cameras, stream live video, record it for future playback, and manage operations on home appliances. A simple client-server architecture for mobile phone based surveillance system is also presented in [5]. In [6] Raty et al. present their research on decrementing the amount of video information transmitted to the end-user equipped with a mobile device. The prototype system described in [7] enables remote high-quality video monitoring from mobile phones by controlling a HDTV-quality video camera using PUCC protocol. Several issues related to the transmission, analysis, storage

This work was supported by the European Union from the European Social Fund (grant agreement number: UDA-POKL.04.01.01-00-106/09).

This is an author's version of the paper. Original version: Proceedings of AFRICON 2013, Pointe-Aux-Piments, Mauritius, IEEE, 2013, pp. 1-6 The final publication is available at ieeexplore.ieee.org: http://dx.doi.org/10.1109/AFRCON.2013.6757671

and retrieval of surveillance video, and a framework for video surveillance from mobile devices are described in [8]. Finally, in [9] Steiger et al. present a video encoding scheme that uses object-based adaptation to deliver surveillance video to mobile devices, applying video object segmentation and selective filtering. In this paper, we show some remarks on choosing video stream encoding for video verification on Android-based mobile devices. The paper is organized as follows. In Section 2 motivating use cases for video verification are discussed. Section 3 consists of an overview of the existing standard types of video stream encodings that are well positioned and widely used in video monitoring. Section 4 describes the architecture of the video verification system that we have developed, and Section 5 shows our experiments on bandwidth usage comparisons for implemented and existing video encoding standards. Section 6 contains a short discussion on our system and final conclusions. II.

MOTIVATING USE CASES

Let us consider some cases where one does not need to record video, cases in which all one needs is to see what is happening right now, and maybe even let us consider a few cases where one specifically does not want or is not allowed to record anything, but is able to see what is going on right now. A. Pet surveillance This scenario is common for a pet owner, the kind of pet that is not locked up in a cage and does not belong in a fish tank. Most likely this pet will be a cat or a dog. Many people have wondered what their pet does when nobody is home. Setting up a video monitoring system would allow to record it all, but the recordings need to be then processed to be useful. After a whole day at work most people will not want to spend the next few hours looking through recordings without a real need for it. Additionally, such recordings quickly add up and fill the disk space that could be better used. Installing a video monitoring system just to satisfy a bit of curiosity seems like a long shot. Setting up a simple remote video verification system as presented in Fig. 1, allows one to check up on their pet whenever they get curious during the day, no matter where they are as long as they have access to their mobile device. B. Place surveillance This scenario takes place in a large house with a garden. The weather is nice so the owner decides to do a grill in the garden. Still there is something they need to watch every now and then that cannot be seen from where they entertain their guests. They might need to check the driveway to check if more guests are coming. They might want to check a taken parking spot just so their guests may park their car there when it gets free. They might be waiting for their neighbors across the street to come back, and they want to check if the lights in their home turn on indicating their neighbors are back. They can check all that personally every now and then. However, taking a look at the phone is much more convenient. And they do not need to see what has happened; they just need to check the current state of affairs.

C. Baby surveillance In this scenario parents with a small child live in a small flat. The parents need to do some work, but at the same time they need to look after the baby. Let us assume the baby has fallen asleep, the parents tuck it in its bed and then go to other room to work. Again, every now and then they will want to check up on the child, but if they are working doing it personally would mean making often breaks. Such distractions definitely do not help in the work that needs to be done. However, as an alternative the parents can simply put their phone on the desk in a docking station and simply spare a glance at the phone every now and then. Only when they see something worrying will they need to stop their work; again, not a matter of necessity, but of convenience. Basically any situation where one needs to check on the current state of things, rather than on what has happened in the more or less recent past, is a situation where one might want to use remote video verification. In almost all these cases one could also set up a video monitoring system that allows remote video verification. It would work well, but it would require more time and resources. This is the advantage of a video verification system. It can be set up in minutes; it does not take much hard drive space so one can always download it or carry it with them on a memory stick. It does not need extensive installation and it does not rely on specialized components. III.

VIDEO STREAM ENCODING

One of the most important decisions about video streaming for video verification is choosing the proper encoding. There are several standard options available on the market [10, 11], as well as a number of less known, often proprietary formats. A. MJPEG One of the older and still popular video encoding standards available is MJPEG. MJPEG is simply a series of still frames encoded as JPEG images [12]. This encoding provides possibly the highest quality of image among all encodings as all frames contain full detail of the recorded scene and are independently compressed as JPEG images according to the compression level selected. MJPEG is a simple video encoding standard that fulfills all but one crucial requirement of the video verification, the stream size. Save for the bandwidth requirement, it would be the perfect candidate. B. MPEG-4 MPEG-4 is an ISO/IEC standard developed by MPEG. It provides an extensive set of mechanisms used for video compression. MPEG-4 introduces the concept of layers and objects [13, 14]. Information about the image is sent not as a whole picture, but rather as a set of information about different parts of the image and the transformations they are undergoing. This allows for a much higher compression rate than offered by MJPEG. Unfortunately, this also means that MPEG-4 is more susceptible to transmission errors. One more limiting factor is that MPEG-4 was not designed to work with high resolution images and works best for resolutions up to 4CIF (704×480 NTSC, 704×576 PAL). The additional improvements significantly increase the compression rate compared to MJPEG, but

at the same time the computational power necessary to encode and decode the stream also increases. In summary MPEG-4, even though quite popular and suitable for most media streaming usages, may not be the optimal choice for video verification. MPEG-4 may be a viable option for encoding in video verification as a middle ground between computational needs and stream compression. C. H.264 Similarly to MPEG-4, H.264 (also known as MPEG-4 part 10) compresses both the full frame, in a JPEG-like manner, as well as the whole video stream based on the changes between frames. This also means that most remarks that were true for MPEG-4 are also true for H.264 [15, 16] it is however built to support Mpix cameras. It introduces new mechanisms for image encoding, which allow for even higher compression rates than MPEG-4. Additionally H.264 brings the encoding granularity to a lower level and instead of working on frames it uses the term slice [17] to denote a part of the frame encoded separately from the rest. Unfortunately all these mechanisms increase processing complexity; early H.264 implementations required a quad-core processor for decoding 2Mpix camera image at 25fps. In effect, although the most prevalent encoding currently due to its compression rate, the H.264 may not be suitable for video verification. Although, it makes working with Mpix cameras, possible due to high compression rates, the computational power needed may be too much for low- and middle-range devices. D. Other encodings Some vendors decided to develop and implement their own encoding standards, mostly by improving MJPEG encoding. An example is encoding developed by a German company called HeiTel [18]. The JPEG image is divided into smaller rectangular parts. Instead of sending the whole image every frame only sends every 10th piece as well as those pieces in which movement occurred. This means that for a still image it takes 10 frames before all parts of the image are refreshed, but any movement is transmitted as soon as it occurs. An example of a recent improvement upon MJPEG encoding is encoding developed by Avigilon company, which was designed to work with high resolution cameras. Avigilon recommended using H.264 to work with cameras up to 2Mpix, and JPEG2000 to work with images from 3Mpix to 16Mpix. The trick was that even though the full frame was received from camera and stored on the server, the client only requested parts of the image that were currently viewed by the user. The transmitted image was also scaled to the resolution of the client, so that only the usable data was ever sent. E. Implemented encoding For our video verification system we have chosen and implemented an encoding that is inspired by the Avigilion encoder. Originally developed for high-resolution cameras (up to 16MPix) it translates very well into an environment where the camera’s resolution is most likely higher than the mobile device screen. Though no longer supported by Avigilion, due to high storage requirements, it provides a few key qualities that fulfill the requirements for video verification. Moreover, it

does not show its biggest drawback due to working only with live images. The encoding bases on passing static frames in JPEG format, it is however not a direct MJPEG encoding. The most important difference is that the client requests from the server any chosen region of the frame and specifies the resolution at which it is to be sent. The server provides cropping and scaling as necessary. IV.

SYSTEM ARCHITECTURE

Our video verification system was implemented using a simple client-server architecture, as shown in Fig. 1. For the purpose of our project only a single server was established. Multiple cameras can be connected to this single server and the server supports simultaneous connections from multiple clients. Though for the purpose of this system a single connection support would be sufficient, multiple connections are supported to extend the usability and improve stability in case the connection hangs and cannot close. Any client can choose to view any of the cameras, though only one at a time. The maximum number of cameras that can be connected to the server is limited only by system resources and will vary depending on the exact configuration. Even though it is stated that only a single server exists, there is no reason why there couldn’t be several servers listening on separate IP addresses and/or ports. The single server support means that the client can be connected to a single server at a time. Thus, if there is a need for a few servers the client will have to alternate between them in order to view images from all the cameras. The OpenCV [20] framework was selected for the image acquisition process. Thus the server supports all USB attached cameras; the only requirement for the USB cameras is to be supported by the operating system. The second reason for choosing OpenCV was that it is one of the fastest image manipulation libraries available. This library especially excels when we need to work with high resolution full frames and process them for the clients. Additionally, as a bonus, OpenCV allows natively for image capture from network MJPEG streams which could allow to easily expand camera selection to some of network cameras without the need to redesign the system from scratch. The mobile software application is designed for low- and mid-end smartphones. As the screen is often one of the most cameras cameras

GSM

server

Internet/WiFi IEEE 802.11

mobile devices

Fig. 1. Overview of the video verification client-server architecture

expensive parts of a smartphone, this stipulates that the screen resolution will be around 480x320. Though this application successfully works with any Android device, regardless of its resolution, the video stream size is highly dependent on the device’s screen resolution. For higher resolution devices, such as tablets, the stream size grows significantly and accordingly the frame rate drops. V.

BANDWIDTH USAGE COMPARISON

Commonly all bandwidth usage comparisons between the different encoding standards are made by the average bandwidth usage. This provides with an easy to understand comparative measure, and allows us to evaluate which encoding will be the most suitable. It also gives a straightforward estimate on the hard drive space required for storage. Unfortunately this simplified measurement approach may be misleading. Encoding standards that rely on differences between frames alternate between sending a full frame and frame changes. This results in network usage spikes [19], which should not be underestimated, especially for megapixel cameras. A full 2Mpix frame saved as JPEG with compression level of 75 (typical compression rate) can be around 160kB. Assuming a 25fps stream this means that a full frame has to be sent in under 40ms. From a simple calculation it follows that for this short time to send that one full frame the network has to be able to transmit about 38Mbps. This is far over the average of 5.7Mbps used by the h.264 encoding. As long as we are considering a LAN or Wi-Fi connection this kind of throughput for one camera is quite easily obtained. Problems arise when we switch to a slower network medium. One solution is to introduce buffering, which (as long as the average stream does not overload the network capabilities) will introduce a delay, but allow for extra time for the full frame to be sent. In our comparisons of the bandwidth usage we made several assumptions to give clearer results: • We have chosen Wi-Fi/Ethernet as a transmission medium to ensure that no results will be negatively influenced by the restrictions imposed by the network. As this project transmits only single camera frames to a client, the chosen transmission medium can become saturated.

possible settings is nigh impossible, part of our result analysis is based on calculations. As a base for our calculations we used a vendor provided CCTV hardware calculator. Such tools are provided by manufacturers of CCTV systems to allow an estimate of how big the bandwidth usage will be, what is the storage space required for a given video monitoring project and how many servers are necessary to run the installation. For the purpose of this calculation a tool provided by Xtralis was used (rev. 1.02). Calculations provided by this tool are based on a full frame size rather than resolution, which allows to apply non-standard resolutions that will be used in mobile devices. In order to ensure a maximum stream size for the implemented encoding a picture of identical proportions to the screen was used. The picture containing a rich in details scene is presented in Fig. 2. In table 1 we show the stream size for a mobile device with a 480x320 screen for the image from Fig. 2 in resolutions ranging from 0.5Mpix to 16Mpix (with steps at typical camera resolutions). Due to the amount of details the frame size is quite significant. The picture was taken with a 16Mpix camera and then resized to necessary resolutions. What is important, it was always resized from the original 16Mpix picture to avoid accumulating JPEG compression artifacts and in effect artificially lowering the frame quality and size. This static picture was resized with JPEG compression level of 75. The resulting set of pictures serves as a baseline for a frame size at a selected resolution. According to these sizes the hardware tool then provided predicted stream sizes. The static picture was also used in place of a video feed to measure the actual stream size for the mobile device directly. In order to keep the same frame rate for all resolutions, a maximum frame rate of 2.2fps was selected experimentally. The laptop serving as server was unable to provide more frames per second when resizing 16Mpix image to 0.15Mpix. In Table 1 we show the result set for the whole range of chosen camera resolutions. The general trend is clearly visible. There is just a small difference between results calculated with the use of the hardware calculation tool and results that were measured. The measured bandwidth is a bit smaller than the predicted one and thus, it catches up to MPEG-4 a bit sooner, at 1Mpix resolution. The predicted result catches up to MPEG4 at 1.3Mpix, and by 2Mpix resolution both the predicted and measured catch up to H.264 encoding.

• For comparison, we have chosen the MPEG-4 and H.264 as the standard encoding technology. • The implemented encoding scheme does not rely on describing changes between frames, as opposed to MPEG4 and H.264 encodings. Therefore, any video streams used for testing will consist of stationary scenes. This will provide better than average results for MPEG-4 and H.264 encodings as the subsequent frames will be very similar to each other. This in turn means that the results for the implemented encoding, in comparison to the standards, will not be enhanced by the chosen scene and rather can be slightly worse than the actual results. As the device selection available for the purpose of video verification is pretty limited and testing the whole spectrum of

Fig. 2. Example frame from test scene

TABLE I.

IMPLEMENTED AND MEASURED BANDWIDTH USAGE FOR RESOLUTIONS IN RANGE FROM 0.5MPIX TO 16MPIX ASSUMING A MOBILE DEVICE OF RESOLUTION 480X320 0,5Mpix

1Mpix

1,3Mpix

2Mpix

3Mpix

5Mpix

8Mpix

12Mpix

16Mpix

Full frame size

110,42kB

194,90kB

234,58kB

328,05kB

448,96kB

671,12kB

975,19kB

1361,27kB

1708,26kB

Processed frame size

44,00kB

45,01kB

45,14kB

45,39kB

45,62kB

45,70kB

45,71kB

45,74kB

45,92kB

Stream size (Mbps) MJPEG

2,43

4,29

5,16

7,22

9,88

14,76

21,45

29,95

37,58

MPEG4

0,49

0,86

1,03

1,44

1,98

2,95

4,29

5,99

7,52

h.264

0,35

0,61

0,74

1,03

1,41

2,11

3,06

4,28

5,37

0,97

0,99

0,99

1,00

1,00

1,01

1,01

1,01

1,01

0,84

0,85

0,86

0,86

0,86

0,86

0,86

0,86

0,86

Implemented encoding calculated Implemented encoding measured

While beating the result for H.264 is most desirable, what is really important is providing quality comparable or better than MPEG-4, as the used encoding was chosen over MPEG-4, while H.264 was never really a choice for our system of video verification due to its high requirements for processing power. It can be quite safely said that for a device with a resolution of 480x320, starting with cameras of 1.3Mpix we provide comparable or better quality than MPEG-4 encoding. Therefore, for mobile device resolution of 480x320, we can say that the viable camera resolution is 1.3Mpix. The reasonable question then arises how viable is changing the camera resolution depending on the mobile device screen resolution. For this measurement four screen resolutions were tested: -

480x320, a typical resolution for a mid-range smartphone such as Samsung Galaxy Ace [22], which was used for most of the tests in this project, it will provide a baseline;

-

800x480, resolution of Samsung Galaxy S2 [23], one of the highest resolutions a high-end smartphone currently has;

-

1280x800, resolution for Galaxy Tab 10.1 inch [24], an Android tablet, a bit outside of the scope of this work, the implemented encoding will surely be a suboptimal choice for this device, but it will provide an extreme value for comparison.

comparisons were made only to compare efficiency of video compression. In fact, MPEG-4 is not suited for high resolution cameras and H.264 provides too much of a computational overhead to be considered for this solution. Therefore, neither of them could be considered to replace the encoding that we have implemented. It is also worth mentioning that the better quality USB cameras currently support capture of still images with resolution up to 8Mpix. For such cameras even if we could use H.264, the encoding implemented by us will provide higher bandwidth efficiency, even though it will possibly come at the cost of limited frame rate. VI.

CONCLUDING REMARKS

After reviewing several papers on video surveillance it can be noticed that video encoding schema is usually adjusted to the goals of the developed system. For example, the video encoding schema proposed by Steiger et al. in [9] uses uncompressed input video and then a set of transformations in order to reduce the transformation bandwidth. Other solutions are based on popular standards, e.g. the system presented by Ishikawa et al. in [7] is based on the H.264, and the one developed by Das et al. [4] used MJPEG. The encoding implemented in our system is also based of MJPEG which means that each sent frame is a full frame. This means that as soon as the user selects a ca-

To allow comparison to the calculations from hardware calculator once again the same static picture was used in tests with the frame rate of 2.2fps. Please note that even though the Galaxy Tab resolution is 1280x800, due to Android Honeycomb always displaying a toolbar at the bottom of the screen the application only had 1280x754 resolution available and for that resolution the measurements were made. In Fig. 3 we show the results of this test. As can be seen, the higher resolution of the device screen, the encoding implemented in our project takes much longer to catch up to MPEG-4 efficiency. For resolution 800x480, which is the highest our system is supposed to support by design, the efficiency of MPEG-4 encoding is caught up somewhere between 2Mpix and 3Mpix, and that of H.264 encoding somewhere between 3Mpix and 5Mpix. Please note that these

Fig. 3. Bandwidth usage for different mobile devices’ resolutions

mera and the frame is downloaded, it is displayed to the user. However, our encoding scheme, though based on MJPEG, allows for a relatively low bandwidth and self-regulation of frame rate, at the cost of lower maximum frame rate achievable. The client requests each frame separately, always specifying its display resolution and displayed image region. The server then scales the requested frame fragment down to the display resolution and sends it as a JPEG image. This allows only data viewed by the user to be sent and only at a usable resolution. It also enables the communication and frame rate to naturally adjust to the current network transmission parameters. This also limits the maximum frame rate by introducing network latency into the communication. However, as presented in Section 5 our encoding method works better than H.264 and MPEG-4 especially for high-resolution cameras (from 2Mpix). The end result is heavily dependent on the disproportion between the full frame size and the mobile device screen resolution, but at the same frame rate it can be several times smaller than H.264 streaming. This comes with a drawback, if the user zooms into the picture he has to wait for the next frame to be transmitted before he sees the image. The architecture of our system is similar to architectures of systems presented in [5-7], even though the implementation and communication protocols are different. As opposed to complex systems like the one presented in [1] the purpose of our system is limited only to video verification. On the other hand, the advantage of our video verification system is that it can be set up anywhere, where there is a need and some common hardware available. This makes it very valuable tool in the domain of home video security. Future works will cover further development of the system, including implementation of intelligent algorithms based on biologically inspired methods, such as evolutionary algorithm, artificial immune system or particle swarm optimizer [25, 26], for discovering specific objects and situations in the monitored scenes and triggering an alarm when the discovery results require user's attention.

[6]

[7]

[8]

[9]

[10]

[11]

[12]

[13]

[14] [15]

[16]

[17]

[18] [19]

REFERENCES [20] [1]

[2]

[3]

[4]

[5]

M. Abu-Lebdeh, F. Belqasmi, R. Glitho, “A 3GPP 4G evolved packet core-based system architecture for QoS-enabled mobile video surveillance applications,” Proceedings of the Third IEEE International Conference on the Network of the Future, pp. 1-6, 2012. W.T. Chen, P.Y. Chen, W.S. Lee, C. Fu Huang, “Design and implementation of a real time video surveillance system with wireless sensor networks,” Proceedings of IEEE Vehicular Technology Conference, 2008. VTC Spring 2008, pp. 218-222, 2008. J. Marais, G. Hancke, “Design of a low cost video monitor store and forward device,” Proceedings of 2012 IEEE International Instrumentation and Measurement Technology Conference (I2MTC), pp. 165-170, 2012. S. Das, S. Chita, N. Peterson, B. Shirazi, M. Bhadkamkar, “Home automation and security for mobile devices,” Proceedings of 2011 IEEE International Conference on Pervasive Computing and Communications Workshops, pp. 141-146, 2011. B. Nahar, M. Ali, “Development of mobile phone based surveillance system,” Proceedings of 13th IEEE International Conference on Computer and Information Technology (ICCIT), pp. 506-510, 2010.

[21] [22] [23]

[24]

[25]

[26]

T. Raty, L. Lehikoinen, F. Bremond, “Scalable video transmission for a surveillance system,” Proceedings of Fifth IEEE International Conference on Information Technology: New Generations, pp. 10111016, 2008. N. Ishikawa, T. Kato, T. Osano, “High-definition surveillance camera control system from mobile phones,” Proceedings of 2011 IEEE Consumer Communications and Networking Conference (CCNC), pp. 1045-1049, 2011. D. Doermann, A. Karunanidhi, N. Parkeh, M. Khan, et al., “Issues in the transmission, analysis, storage and retrieval of surveillance video. Proceedings of 2003 IEEE International Conference on Multimedia and Expo (ICME), vol. 2, pp. 161-164, 2003. O. Steiger, T. Ebrahimi, A. Cavallaro, “Surveillance video for mobile devices,” Proceedings of IEEE Conference on Advanced Video and Signal Based Surveillance (AVSS), pp. 620-625, 2005. Axis Communications, “Technical guide to network video,” http://www.axis.com/products/video/about_networkvideo/index.htm (accessed March 10, 2013). Avigilon, “Understanding Compression Technologies for HD and Megapixel Surveillance,” http://avigilon.com/assets/pdf/WhitePaperCompressionTechnologiesforHD.pdf (accessed March 10, 2013). P. Schelkens, A. Skodras, and T. Ebrahimi, “The JPEG 2000 Suite,” Wiley, Series: Wiley-IS&T Series in Imaging Science and Technology, 2009. J. Kneip, B. Schmale, and H. Möller, “Applying and implementing the MPEG-4 multimedia standard,” IEEE Micro, vol. 19(6), pp. 64-74, 1999. L. Chiariglione, “Inside MPEG-4 – part A,” (accessed March 10, 2013) http://ride.chiariglione.org/MP4_inside_part_A.php T. Wiegand, G.J. Sullivan, G. Bjøntegaard, A.K. Luthra, “Overview of the H.264/AVC video coding standard,” IEEE Transactions on Circuits and Systems for Video Technology, vol. 13(7), pp. 560-576, 2003. T. Stockhammer, M.M. Hannuksela, T. Wiegand, “H.264/AVC in wireless environments,” IEEE Transactions on Circuits and Systems for Video Technology, vol. 13(7), pp. 657-673, 2003. G.J. Sullivan, P. Topiwala, A. Luthra, “The H.264/AVC Advanced Video Coding Standard: Overview and Introduction to the Fidelity Range Extensions,” SPIE conference on Applications of Digital Image Processing XXVII, pp. 454-474, 2004. HeiTel, “Professional CMS Solutions with a Green CCTV Approach,” TechCorner, pp. 119-122, 2011. Fan Zhong, “Bandwidth Allocation for MPEG-4 Traffic in IEEE 802.11e Wireless Networks Based on Traffic Prediction,” Future Generation Communication and Networking (FGCN 2007), pp. 191196, 2007. G.R. Bradski, V. Pisarevsky, “Open Source Computer Vision Library,” Springer-Verlag New York Inc., 2004. Axis Communications, “Axis Design Tool,” (accessed March 10, 2013) http://www.axis.com/products/video/design_tool/users_guide.htm Samsung, “Galaxy Ace Tech Specification,” (accessed June 20, 2013) http://www.samsung.com/galaxyace/ace_techspec.html Samsung, “Galaxy S2 Tech Specification,” (accessed June 20, 2013) http://www.samsung.com/global/microsite/galaxys2/html/specification.h tml Samsung, “Galaxy Tab 10.1 Tech Specification,” http://www.samsung.com/global/microsite/galaxytab/10.1/spec.html (accessed June 20, 2013) T. Burczynski, W. Kus, A. Dlugosz, A. Poteralski, M. Szczepanik, “Sequential and distributed evolutionary computations in structural optimization,” In: L. Rutkowski, et al. (eds.) Artificial Intelligence and Soft Computing, vol. 3070, Springer, Berlin, Heidelberg, pp. 1069-1074, 2004. T. Burczynski, A. Poteralski, M. Szczepanik, “Genetic generation of 2-D and 3-D structures,” In: K.Bathe (ed.) Computational Fluid and Solid Mechanics, vol. 2, Elsevier, Amsterdam, Netherlands, pp. 2221-2225, 2003.