Navigation

Remote IP Camera Monitoring Project

INTRODUCTION

The fundamental goal of this project was to provide remote monitoring of a property in Europe from Canada.

The requirement was that any images triggered by a "motion" event be sent to the local (home) web server for subsequent display as web pages. Further, security images from up to 2 months should be available on-line on the web server. Security images and web pages that are older than 2 months will be moved to an on-line archive.

Additionally, each camera's live images need to be accessed by remote logon-on to each camera. This allows access to the camera for changing settings or viewing live images of the camera's surroundings.

SURVEILLANCE CAMERA TYPES

There are three types of cameras used in surveillance/security systems. What is common to most security systems is the ability to record an event, such a motion detection, alarm notification to the user and recording of alarm events which is then available for playback by the user through either a web page or a phone application. The camera's motion sensitivity can often be adjusted to reduce false alarms.

Video Cameras

Common security systems use three types of cameras.

Wired Video Cameras

Surveillance systems that are local to a home or small business use wired cameras that send a video signal to a central CCTV recorder. The recorder contains the processing logic to provide a way of the user to viewing the cameras either through an interface such as a web page or through a phone application. The cameras provide the video signal to the recorder and the recorder provides the voltage to power the cameras. The cameras themselves are quite simple. LOREX Recorder and camera

As the cameras are wired to the recorder for the video signal and its power; there is a limit on how far the camera can be from the recorder, the maximum is typically 150 feet. Longer distances result in degraded video to the recorder and a drop in voltage (line resistance) to the camera. This is why this type of surveillance system is used to monitor more localized areas, such as a small business.

All functions are managed by the recorder; alarms, image storage and playback, communications and user interface are managed by the recorder console. An example of a provider of these systems is Lorex.

As with most security providers, Lorex, has a phone app that the user can view remotely the activity of all the cameras. The Lorex LHA4104LC recorder also features a web interface which a user with some router configuration and DynDNS skills can access remotely as well if the phone application does not work.

The recorder uses a Peer-to-Peer (P2P) method for locating the camera when the camera's phone app is initiated. When it's powered up, the recorder sends its unique ID to the manufacturer's P2P server to report its IP address, thereby creating an outbound connection which the user's home/business router permits.

How P2P Camera Video Streaming Works

How P2P Camera Video Streaming Works
Source: Author

  1. When the user opens their security phone app to access the recorder, the phone app connects to the same manufacturer's P2P server.
  2. The server matches the phone app to the remote recorder.
  3. This creates a direct data connection between the phone app and the recorder. This bypasses the need for router port forwarding, static IPs or dynamic DNS IP (DDNS) service configurations.
  4. The video streaming between the recorder and the phone is stablished.

Ultimately the recorder and phone app are dependent on the manufacturer's P2P server. Should the manufacturer cease support for the hardware, as has happened to some (e.g. Blackberry, Sony, Qardio, etc.), then the phone app will no longer work.

Some recorders also feature a web interface, such as some Lorex models. If Lorex ceased business, the user could still access the recorder's interface through a web browser but this would require the router to be configured with port forwarding to the recorder's internal IP address and an internet facing static IP or DDNS reachable address.

One drawback to this type of security system is if a criminal removes or destroys the recorder, then all video history is lost and the user has no video of the robbery.

IP Cameras

A type of camera used for wider area surveillance is the IP camera. The IP camera is more complex. Each camera is basically a stand-alone computer with in-built image processing and data transmission capabilities over TCP/IP. Each camera will have its own unique IP address which can be accessible by an operator. These cameras rely on a central application server to display the images but do not rely on the server for raw image processing. The camera also does not save any images locally, it relies on an external server for image storage (NAS) or post processing.

IP Camera Network

IP Camera Network
Source: Author

You can recognize an IP camera by its RJ45 Ethernet port. IP cameras are ideal for monitoring larger widespread areas, such as airports, because they can tap into a wider area TCP/IP network. IP Camera Connect one into a network switch and it's accessible by its IP address by any computer on the same network. Each camera also supports dynamic IP configuration (DHCP). These cameras support Power on Ethernet (PoE) connectivity, meaning that a PoE network switch has the capability to provide power to the camera over its RJ45 ethernet cable.

Alternatively, if the network switch does not have the PoE capability, the camera can also be powered by an external 12VDC adapter. This is impractical for large surveillance networks with cameras in places that may not have access to an electrical outlet for the adapter.

A wide area network can be created with PoE switches and geographically dispersed cameras. A manufacturer's application is often available to monitor the feed from the cameras centrally.

IP Cameras - Wide Area Network Deployment

IP Cameras - Wide Area Network Deployment
Source: Author

One advantage of these cameras is that they rely on a central server to store the images. The server does not have to be close to the cameras; the server could be miles away or in another country. Should the cameras be stolen or damaged, the security images are saved on the remote "cloud" server. It is impossible for anyone, local to the cameras, to erase the security images.

Standalone Security Cameras

A third type of camera is the standalone camera which contains the image processing, local image storage and communications over TCP/IP or UDP. Its images are typically viewed through a phone app. These cameras often have features such as movement detection, alarm notification, event playback and real-time viewing. Some cameras even allow the user to hear what is happening at the remote location and talk back through the phone and the camera's built-in speaker. These cameras are quite popular, have extensive features and are low cost. System B Chassis They meet the requirements of most residential users who only need one or two cameras for residential or small business monitoring.

It is similar to the IP camera insofar as having image processing, motion detection, motion tracking, alarms, two way communications and TCP/IP communications. Similar to video recorders these cameras rely on a vendor's P2P server to be located by a phone application. Without an associated P2P service, neither the phone application nor the cameras will function. Some camera models have more features and area more technologically advanced than the IP cameras.

Security images are stored on an SD card within the camera. The "TF card slot" on the right image is where the SD card is inserted. The larger the SD card, the more days of monitoring that can be stored on the card for user playback. In effect, this is a distributed recording system; whereas the LOREX type of recorder centralizes the image recording on a central large disk within the recorder, these cameras store their individual security images on the SD card. The phone application facilitates access to the security recordings stored on each camera's SD card. Without the SD card, these cameras have no playback capability.

Live playback is facilitated by the phone application by setting up a live stream from the camera through the phone application. The P2P connection is first mediated by the manufacturer's service to setup the connection between the user's phone and the remote camera.

Some manufacturers also offer a cloud service option, whereby the camera images are uploaded to the vendor's cloud instead of the SD card. If the camera is damaged or stolen, the images are still available to the user from the cloud.

Similar to the IP Cameras, each camera has its own unique IP address on the user's network. The cameras also support DHCP. There are many similarities between IP Cameras and these standalone security cameras.

Security Camera Network

Security Camera Network
Source: Author

The consumer oriented phone applications supporting these cameras are ideal for one to four cameras. However, aggregating images from a large number of cameras is problematic as streaming from each individual camera has to be aggregated into one phone application, which can overwhelm the capacity of the phone and lead to slow application response.

The cameras communicate with the user's router wirelessly, but still need to be wired to a power adapter. This limits the placement of these cameras as they still need a 12VDC power source. The 12VDC adapters often provided with the cameras are often not meant for outdoor use and therefore the adapter has to be placed inside a building if the camera is to monitor the outside. This isn't a problem for security cameras inside a home. For those applications requiring cameras outside a home, some manufacturers provide a solar cell based power supply, to get around the wiring restrictions.

One clever way of bypassing the power adapter issue is the wireless bulb camera, which inserts into a standard lightbulb socket and derives it's power from the socket. These cameras work on 110 and 220V power, making installation very flexible either for in a house or outside use.

Any camera for outside use should meet the IP66 standard which specifies the camera has dust and water (rain) protection.

PROJECT SCOPE

The goal of the project is to provide a way to monitor locally, 24 X 7, through a web browser the security images from remote cameras in another country. The requirements are:

  1. Camera images are transmitted when triggered by motion within the camera's field of view
  2. Provide a method to collect and review security images transmitted from remote cameras. In effect build a "cloud" for image capture
  3. Images need to be organized by day; one webpage per day for images collected for that day
  4. Images must be viewed through a web browser
  5. Daily image web pages must be accessible for 20 days on-line
  6. After 20 days, web pages and associated images must be moved to long term archive and purged from the web server
  7. Access to the images and associated web pages must be available through the public internet and local intranet
  8. Each camera must be remotely accessible for configuration changes and real-time event monitoring

IMPLEMENTATION

Two TRENDNET IP cameras were used for this project. The implementation approach selected was based on the features of of these cameras.

Network Topology

The IP cameras are directly connected by Ethernet cable to a PoE Switch, this provides power to the cameras through the Ethernet cables. This is preferred over running a separate 12V power source to each camera. The PoE switch is then hardwired to the router over Ethernet. The router sits on the Internet through a local European Internet Service Provider (ISP). Image transmission and real-time access is accomplished using this configuration.

IP Camera Network Configuration

IP Camera Network Configuration
Source: Author

Note: web page addresses for illustrative purposes only.

The cameras can store images to a local Network Server (NAS) or transmit then over FTP. Since there is no remote server available, the images are sent to the FTP server. Port forwarding on the router allows the FTP connection to pass through to the FTP server where the files are stored for processing.

On the monitoring side the camera's images are processed and then displayed as web pages.

Software Approach

The application to consume the FTP images sent over TCP/IP from the remote cameras is explained below. This application runs on the same server as the web server so that images received and web pages created by the application can be directly moved to the web server for user access.

Monitoring Software Architecture

Monitoring Software Architecture
Source: Author

The monitoring application operates as follows:

  1. Image files are received from the remote cameras over FTP.
  2. The images are saved into a directory for each camera. So that Camera 1 will have it's own unique directory for image storage and so does Camera 2 have its own directory.
  3. Each camera has a copy of the application running. There is no one application that manages all cameras; for the sake of simplicity, each camera has a counterpart copy of the application running on the server. Every three minutes the application examines the FTP directory (e.g. RCVR2) for the presence of images.
  4. The images are moved to the CAM2 directory via a CMD shell batch script. During the day, whenever there are images in the FTP directory they are moved to CAM2. This is a working directory.
  5. The same script moves the images to the web server so that when the monitoring web pages are created the images are ready to be pulled in.
  6. Based on the list of images in CAM2 several web pages are created. First is the MAIN web page which is a list of all images received today and the timestamp when they were created as a result of an alarm trigger.

    However, an issue was found when receiving images from the TRENDNET cameras. These cameras sends six images for every event triggered, for example; motion detection. Changes to ambient light, laundry fluttering in the wind, a night light turning on, any small movement; all triggered multiple alarm events. This resulted in an unexpectedly high number of images to process and list on the day's web page. By day end, there were literally thousands of images. This was too many images to review to understand what triggered the alarm. The challenge is which images showed the movement versus which of the six images were just similarities to its next. How to denote which of the six images contain what triggered the alarm?

    The solution was for each image to compare itself to the previous image received. The application creates a batch script that uses an external CMD level program to compare the current image against the previous image and produce a percent difference score. The application Shells out the batch file in CMD and collects the result. It does this for every image in CAM2 directory. Any image that is 9% different from its previous stored image gets a star next to its link on the MAIN.HTML web page. These are the images the user should focus on.

    MAIN.HTML Example

    MAIN.HTML Example
    Source: Author

    The page above shows the final layout for the image file. On the left is the navigation page which points to image pages for every day processed. On the right side is the image page for February 25th. By clicking on the camera icon, the user can see the associated image. Note that entry 13 on the "Ref" column, the image has a 16% difference from the previous image. Likely that image shows what caused a motion trigger. A star next to the percentage reading indicates this is worth reviewing.

    An intermittent issue came up after the batch script was run and the next one started. Unexpected ile system errors cropped up. The assumption being that the percent difference file was not yet closed by the time the next batch script started. To correct, necessitated a one second wai time between batch scripts. This image comparison processing time was negligible, but now the processing took one second for each file.

    Initially, as images were received during the day, a comparison of all image files was processed and the web page is re-created. That is for 1000 files, the comparison now took 1000 seconds. As the comparisons were run every time a new image file was received, excessive time was spent comparing images. The way to resolve this was to save the comparison results in an array whenever a comparison was run. When new images were received the comparison was only run on those images and their result saved to the array.

    Two other web pages are created; IMAGEI.HTML which is a grid display of all images received during the day and IMAGEB.HTML which is a grid of only images that scored 9% and above on the difference calculation. The latter is a smaller web page containing less images but the pertinent ones worth reviewing.

    02-26-06_2.HTML Example - End of Page

    02-26-06_2.HTML Example - End of Page
    Source: Author

    The web page above shows the statistics for this daily web page. There are 942 security images available to review. The compiled date/time shows when the page was created. It also shows the number of motion events; triggers detected. These would have been caused by motion detected and triggering an alarm; this shows there were 49 such events. Finally, the comparison trigger is 9%, this denotes that any image that is 9% different from the previous image will get a "*" next to it for attention. Likewise the similarity threshold for the brief web page is also 9%, but could be set higher or lower in the code. Any images that are 9% different or higher from the previous image are on the brief page.

    Once all image processing completes and the web pages are created, the application suspends itself for three minutes before checking if more images were received. If the program detects it's the next day, it purges the images from CAM2 and awaits for the new day's images to be received so processing can resume again. Recall that CAM2 is a working directory of images to be processed for that day only.

  7. On a daily basis an image archive application is run.
  8. It creates a master index page for both cameras CAM.HTML. Its an anchor page for the user to start with so they can access the latest image web pages for both cameras.
  9. If the web image web pages (MAIN.HTML) are older than 20 days, then the associated images and web pages are moved to an external archive disk. Note that each day a new MAIN page is created as alarms are usually raised every day for various reasons and each alarm generates six images. This cleanup and archive process prevents the web server from filling up with thousands of images and impeding its operation.
Other Issues

The unexpected high number of incoming files and the frequent scanning for images, could wear out the cloud computer's SSD C: drive prematurely due to the high number of writes. SSD drives have a finite number of writes before they fail. To reduce the disk wear, a 3GByte memory disk was created (R:). The images and batch scripts were moved to R: so most processing occurs on the memory disk.

Room for Improvement

In developing the code and adding functionality in an incremental, experimental approach, some application development decisions were sub-optimal. The code to run each camera should have been one re-entrant module; one common code block that can process "n" number of cameras. The current application must have one copy running per camera.

Parameters for percent image differences, suspend time between program runs, number of days before image archiving and location of the archive directory are currently hard coded in the application. Ideally these parameters would have been loaded from a configuration file so the program would not have to be compiled for every parameter change.

Resources

Compiled on 04-01-2026 22:42:25