Cat 6a cabling, do you really need it for IP Video?

In security, modern IP video CCTV camera systems inevitably involve support from the IT/Data Communications departments now, and we often get asked about “how much” bandwidth is needed and what cabling types we need for the cameras, switches, and servers.  Often our advice is in conflict with the IT corporate standards, and we end up explaining the practical use for video in security.  This article attempts to discuss in layman’s terms the differences in the cabling types, and how they relate to IP video security.  The actual physics behind the IEEE 802-series specifications are complicated and beyond the scope of this document (fair warning: that rabbit hole goes deep).

In order to understand the basic question, some explanation is needed on the different types Ethernet cabling, and their capabilities and limitations. It’s mostly about increasing the frequency capabilities of the cable.  Cat 5e is built to meet the specification requirements of up to 100 MHz, Cat 6 takes the spec to 250 MHz, and Cat 6a takes it all the way up to 500 MHz. The main difference between these cabling standards is the amount of insulation for the conductors and the rate of twist, although there is also a slight increase in the gauge size for Cat 6 also.   The net effect of these modifications is to reduce crosstalk, attenuation, and EMI.  This can also have the effect of reducing propagation delay and delay skew, which can be measured in millisecond increases in transmission times in some cases.  Delay is known in all types of transmission media, even fiber optics, and is the amount of time that passes between the transmission of a signal and when it is received at the other end of the data link.  In collision based networks like Ethernet using TCP/IP, minimizing propagation delay and skew can have an increased effect on the efficiency of the network and the net amount of data that can be transmitted upon any given network.  Dropped packets mean re-transmission, and bandwidth gets eaten up by repeating data information that’s already been sent (at least) once before.

Cabling Standard Limitations

Cable Type Max Distance Max Data Rate
Cat 5e 100 Meters 1 Gbps
Cat 6 50 Meters 10 Gbps
Cat 6a 100 Meters 10 Gpbs

Cat 6 was the first entry into copper based 10Gpbs data transmission at a commercial scale. The problem with Cat 6 is that after 50 meters the data rate is essentially 1Gpbs, or no better than Cat 5e.   Cat 6a was later introduced and will do the full data rate of 10Gbps for the full rated distance for Ethernet (100 meters).  However, Cat 6a cabling is significantly larger in diameter than Cat 5e and has a stiffer jacket, making cable installation more difficult.  It’s also more expensive, about 33% more expensive than Cat 5e.

But do you really need 10Gbps at the edge device?  Probably not for most applications.  Even current high resolution cameras would not be able to fully utilize a 10Gpbs network, never mind that the server hardware on the other end processing a couple dozen full rate video streams would be overwhelmed.  Currently, high resolution 3 megapixel (MP) cameras are widely available on the commercial market.  At 30 frames per second (fps) and at full resolution, it would consume a maximum data rate of 15,000 kilobits per second (Kbps), or 15 Mbps, and more likely it would consume quite less.  In most security applications, resolution and data rates are throttled not because of bandwidth limitations as much as for storage limitations on the server.  Exceptions to that would be the gaming industry and congested high speed traffic areas such as toll booths.  But for most of our applications, we typically find 2MP cameras at 10fps a reasonable compromise that consumes less bandwidth (and disk space) while still providing adequate video information for surveillance, response, and investigation.

Common Camera Resolution and Bitrates

Resolution (MP)
Pixels Frame Rate (fps)
Bitrate (Mbps)
1.0 1280 x 720 30 6
2.0 1920 x 1080 30 10
3.0 2048 x 1536 30 15

Even at full resolution and frame rate, you could theoretically put eighty-three (83) 3MP cameras (1250 Mbps/15 Mbps) on one 10GBase-T network cable. Of course in reality it would be considerably less, but you get the idea.

So where is 10Gpbs Ethernet really needed?  For now, backbones.  Those connections from network switch to network switch that are relaying end device connectivity to other devices, clients, or servers.  Often these are fiber optic links, but more and more they are being made available as copper links and using Cat 6a.

So what do we recommend?  Given the additional cost and current technical capabilities of IP cameras, we typically recommend Cat 6a cabling as sufficient for all IP video cameras where the 100m distance limitation is held and special conditions that require fiber optic cable or special media converters don’t apply.  There are also some technical concerns on the terminations and number of cycles for insertion/reinsertion that can come into play due to the cable’s rigidity.  Cat 6a is readily available, inexpensive, offers much easier cable handling and termination than Cat 6A, and still offers 10Gbps data rates on shorter runs.

Still, if the objective is to “future proof” your installation, Cat 6a is among the latest and greatest and should ensure that even 100+ MP cameras of the future would be handled without re-cabling.

Posted in: Security Technology

Leave a Comment (0) →

The Impact of Closed Circuit Television

Almost 30 years ago when I was first entering the security industry, closed circuit television (CCTV) cameras weren’t terribly different from the cameras that were being used to for movie and television production.  They were smaller, typically had less resolution and no audio, but the basic principles were the same.   Charged Coupled Device (CCD) cameras were fairly new, and if you wanted low light performance, you were resigned to use tube cameras.  Yes, tubes.  As in vacuum tubes.  Tube cameras actually used a vacuum tube for the imager, and the tradeoff for low light sensitivity was a shorter life span, higher power requirements, and reduced reliability.   Later, Complementary metal–oxide–semiconductor (CMOS) cameras came into play and helped overcome some of the limitations of both tube and CCD technologies.

Vidicon Imaging Tube for Old Style CCTV Camera

Since then, digital Internet Protocol (IP) cameras have come into play.    These newer cameras offer increased light sensitivity, much higher resolution, and new enhancements like video analytics and flexible communications options.

While all of these advancements make for better security, the most important enhancements are the video analytics and IP communications.   These two technology advances increase the likelihood of detecting activity and being able to monitor and record that activity from almost any location.

For most small and medium sized businesses or municipalities, the thought of a comprehensive video management system seems not only unnecessary, but impractical from a monitoring and timely intervention standpoint.  “Video cameras don’t stop crimes, all they do is record it”, we often hear.  This is not necessarily true.  CCTV video serves three important roles in security:

  1. Deterrence – Sometimes just the sight of a video camera will deter criminal activity from ever happening in the first place. Because being watched means being held accountable, this is a strong enticement for on premises security cameras.  No, this doesn’t mean adding “dummy cameras” is a good idea.  In fact, installing dummy cameras can make matters worse in premises liability cases for incidents occurring on your property.
  1. Detection – Having all of the campus CCTV cameras monitored in a single location allows for an operator to spot potential negative events during or even prior to them actually happening. IP enabled cameras offer increased detection capability in two ways; first they allow for cameras to be placed anywhere within the corporate network infrastructure (or even further away via hybrid cabling or wireless networking), and second they permit remote monitoring from anywhere there is network or internet access, including smart phones and tablets.  This allows for remote monitoring and recording at an off-site or contract monitoring facility, and also allows the ability to feed recorded or live events to first responders almost in real-time.    It also means that cameras can be located just about anywhere in your corporate footprint, including on-board vehicles.
  1. Assessment – Being able to discern what, where, and when something is happening on camera is critical to determining how to respond to a particular event, and also aids in evidentiary requirements for later prosecution. With the advent of video analytics, that can now be taken a step further with things like video motion detection, face detection, traffic movement, object removal, and facial recognition.   These tools increase the reliability of the observer (or recording device) to actually capture useful video information for use in timely intervention or for evidence in prosecution.   For example, with the right software, imagine a disgruntled employee situation where the former employee’s photo is setup to trigger an alert if the video system “recognizes” his face when he tried to re-enter the campus.  The authorities can be notified and other emergency precautions can be taken much sooner than previously possible.

Each one of these roles is an important piece to the overall security strategy for a business or government entity, and when used with common sense security practices like Crime Prevention through Environmental Design (CPTED) and other industry best practices, CCTV video becomes a powerful tool to both deter, detect, and defend both persons and property in a timely and effective manner.

 

Posted in: CPTED, Premises Liability, Security Consulting, Security Technology

Leave a Comment (0) →

A Theory on the Yahoo Security Breach and Your Instant Messenger Service

In September of 2016, at least 500 million Yahooatb_yahoo_messenger accounts have been affected in one of the largest data breaches in history.  My Yahoo account was one of them, although I only used it as a personal dump account for registering on non-essential websites.  Luckily I kept no personal or financial information in any of the emails there.

Most people, including the media, seem to be concerned with how this will affect the Verizon deal acquiring Yahoo.  Indeed, I’m certain Verizon is VERY concerned with it.   But that’s not the interested thing.  The interesting thing is that Yahoo isn’t talking about HOW the data breach occurred, or if it’s connected with the prior data breach in August that stole 200 million accounts.  Or that the data breach seems to simultaneously occurred with a rather hastily put together service migration of the well used Yahoo Instant Messenger (IM) platform.

More importantly and much less publicized, in August of this year Yahoo completely abandoned the venerable and well documented Yahoo Instant Messenger service, instead offering a dumbed down, less feature-rich service by the same name.  Most transitions of this scale and magnitude would take months or years for the migration, but this happened very quickly, leaving 3rd party vendors (Pidgin comes to mind) without much recourse for their offerings.  After August 5th, anyone that was still using the legacy Messenger app (or the API) was no longer be able to log in or send messages.  You couldn’t even log in…

Yahoo IM is well known to have some security concerns, including the ability to “see” anonymously and remotely if someone is online using it, even in invisible mode.  It also had a very well liked and well used archival feature that recorded the entire text conversation for audit purposes.  Many brokers and traders used this platform to buy/sell products and put together deals very quickly.   They loved it.  But the new version does not support this feature (among others), and brokers have been forced to migrate to other platforms like ICE.

So what does all this tell us?  It tells me that there was likely a very serious security flaw in the Yahoo IM protocol, and that it likely had been exploited to gain access to millions of accounts without the users’ knowledge.   Any time a Fortune 500 company abruptly switches out a venerable product and substitutes it with a hastily deployed, inferior product, you can bet your hat that there was something significantly wrong with it.

Meanwhile, Yahoo is hush hush about it, not even mentioning the curious and spontaneous change to their IM platform that so many have relied upon for years.

Posted in: Security Technology

Leave a Comment (0) →

LED Street Lighting for Security Purposes

Drive down any US city street these days, and the led-lightsold, yellow street lights now shine bright white and bright with the latest in modern street lights, LEDs.  LED lights are popular because of their tremendous energy savings, about 80-90% energy efficiency, when compared to a traditional incandescent light bulb. This means the LED lamp has about 80% of the energy used to illuminate actually goes into making the light, with the remaining 20% given off as thermal energy.   Compared with the highly inefficient incandescent bulb, which is about 25% converted to light, and 75% given off as heat.   So for any business, residence, or municipality, a huge savings in operating costs can be found by switching to LED lighting, and with federal subsidies for energy savings, the capital costs are partially offset as well.

But a small wrinkle has developed as the American Medical Association (AMA) has adopted guidance for communities on selecting among LED lighting options to minimize potential harmful human and environmental effects.   People are complaining about driving under the blue-white lights, or trying to sleep with one newly installed on the street outside their bedroom window.  According to the AMA:  “High-intensity LED lighting designs emit a large amount of blue light that appears white to the naked eye and create worse nighttime glare than conventional lighting. Discomfort and disability from intense, blue-rich LED lighting can decrease visual acuity and safety, resulting in concerns and creating a road hazard.  In addition to its impact on drivers, blue-rich LED streetlights operate at a wavelength that most adversely suppresses melatonin during night. It is estimated that white LED lamps have five times greater impact on circadian sleep rhythms than conventional street lamps. Recent large surveys found that brighter residential nighttime lighting is associated with reduced sleep times, dissatisfaction with sleep quality, excessive sleepiness, impaired daytime functioning and obesity.”   So the AMA is recommending that LED street lamps that are installed turn the color temperature down from 5000K or 4000K to at least 3000K, or a “warm-white” color that more mimics natural sunlight.

For the last 30 or 40 years, most street lamps have been high pressure sodium or mercury vapor lamps.  These are high intensity gas discharge (HID) lamps that operate by forcing an electric arc through vaporized mercury or sodium to produce light. The arc discharge is generally confined to a small fused quartz arc tube mounted within a larger borosilicate glass bulb.   The color is the big difference:  mercury vapor lamps usually produce a bluish/purple color when operating, and sodium lamps produce a yellowish/brown color.   Sodium is the most common type lamp until just recently because it was more efficient than mercury.

So what difference does this make from a security standpoint?  The color mostly…  Oddly from a security standpoint the color can make a difference from a psychological and electronic security perspective.   In the past we have generally recommended Metal Halide HID lamps instead of mercury or sodium, even though they operate similarly, because the color is a much more true white and allows for proper color identification in low light situations.  Mercury and Sodium lamps can make greens and reds look like different colors, and navy and black almost impossible to differentiate.  Enter LED lamps.  They look very similar to metal halide from a color perspective, and allow better color rendition for both human eyes and electronic eyes such as video surveillance cameras, most of which see in color these days even at night (if the lighting is good enough).  Below you can see the major difference between an older style sodium vapor lamp and a newer LED.

Old and New

Both lamps give off ample light, but there is an obvious color difference.  And while it’s not terribly easy to see from this photo, true accurate color renderings are harder with the yellow sodium lamps.   The LED lamp here is a hotter color temperature, around 4000K and has that bluish tint that is being complained about.   Lowering the temperature to 3000K would make it slightly more amber, but not anywhere near the color of the sodium lamp.

So if your business, facility, or municipality has LED lamps being planned, it may be prudent to push for a 3000K color temperature not only for security camera color rendering accuracy, but also from a psychological and health perspective, and you have the AMA helping make your case for you.

 

 

Posted in: Company News, CPTED

Leave a Comment (0) →

Review – Samsung SND-7084 3MP Minidome IP Camera

SND-6084R_PD1

The Samsung SND-7084R is part of the WiseNetIII family of cameras from Samsung with 3 megapixel 1080p high definition images. It’s high level of functionalities includes 120dB Wide Dynamic Range which delivers 30fps at 3MP (60fps at 2 MP), low light performance down to 0.1 lux (F1.2, 50IRE, color) creating clear images in low light conditions, and has a built-in 2.8x motorized varifocal lens for easy focus  control.  The (R) designation in the model number is for IR illumination, allowing for 0 Lux B&W viewing.  The unit is designed primarily for ceiling mounts, but a variety of mounting options are available from the manufacturer for alternative mounting options.   Average Retail Price: under $600.00.

Notable features: 3MP @ 30FPS, Motorized zoom (3 ~ 8.5mm, no motorized pan/tilt but can be adjusted manually), Micro SD/SDHC slot, True Day/Night vision, IR LEDs for 0 Lux operation, Bi-directional audio capability, analog video out, intelligent video analytics (Tampering, Virtual line, Enter/Exit, (Dis)Appear, Audio detection, Face detection with metadata), defog, vide stabilization, and IPV4/IPV6 network connectivity with SSL, 802.1X, and QOS and full SNMP support.

Upon unboxing, the camera looks very well built, and includes all the connectors, mounting screws, and torx bits to install and service the camera.  The included documentation was sparse, but the full online document manual is on disk and also available online here.  The installation hardware includes both an “L” shaped torx wrench and a torx bit for a drill for easier installation.  The camera housing is aluminum metal, with a tough lexan material dome suitable for vandal resistant applications.  The dimensions are Ø132.1 x 107.6mm (Ø5.2″ x 4.24″), weight is 575g (1.27Lbs).  Electrical requirements are 24VAC/12VDC @ 10W or PoE (802.3af Class 3) @ 11W maximum.  Operating temperature range is -10°C ~ +55°C (+14°F ~ +131°F) / Less than 90% RH.

SND-7084R

The camera has some nice additions that aren’t found on competing models, such as a dedicated analog video output connector, a built in SD/SDHC slot for video storage, audio in/out, zoom/focus switches on camera, defog fan, and phoenix connectors for power connections.

The CAT5 connection includes power and connectivity lights, but the orientation inside the case makes it such that connectors with long strain reliefs may be hard to fit inside the case.  In most cases the cable will be field terminated anyway, so it’s probably not a big problem.  Waterproof grommets are included to ensure a water tight seal for exterior installations.  If you elect to use the additional connectors, note that they have fairly long leads on them, so be sure to include additional room in your mounting configuration.  Although for most installations, a single CAT-5E cable is all that should be needed.  There is some indication in the Samsung documentation that audio is available via a built-in microphone, but we could not locate a microphone anywhere on the unit, and were unable to hear any audio without the addition of a discrete microphone added to the audio input.  We did not test the talk-back audio output feature.  The connector to the left of the CAT5 connector is a multi-feature connector which has the audio in/out and alarm in/out harness.  The alarm input/outputs were not tested.

 

DSCN1019DSCN1015DSCN1016DSCN1017

 

Setup

We connected the camera both with 12VDC power and a standard 100BaseT Ethernet connection, and also with a PoE Ethernet connection.  The camera booted up and connected via DHCP quickly under both configurations.   We used the MAC address to find the IP assigned, and connected to the camera using Firefox on a Windows 10 computer.   Note that like most IP cameras, you will need to first download and install their specific codec in order to view any video.  This necessary step is a hassle because it requires a browser restart, but it only needs to be done once.

Samsung-Setup-Screen

When first connecting to configure,  you must set a password…  a really, long, complex password.  For testing, I just set it to “Admin1223!”.  Username default is “admin”.  The setup configuration menus are intuitive and fairly common among other IP cameras, and the menus were very responsive and quick to acknowledge configuration changes.   We first connected to verify we had video, and then began looking at default configuration settings and features.  Since nobody likes upgrading firmware, we pleasantly noted this unit shipped with the latest version of firmware, which as of this writing is 3.00_140915.  Notable features on the configuration defaults are that SNMP V2 is on by default with public read/write, DHCP is enabled by default (this is a good thing), and UPnP and Bonjour discovery services are enabled by default (this is not a good thing).

Date/Time – The camera also supports timezones and NTP time synchronization, with support for up to 5 NTP servers (why, we’re not sure, but okay).  TCP ports are also fully configurable for HTTP, HTTPS, RTSP, and the Device Port.  IPV6 is disabled by default.

Users – Multiple users are supported, and we recommend setting up an NVR user/password and then  making the default admin password really complex (it should already be anyway).   It does not appear possible to rename the admin user or delete it.   You can also have RTSP connections without authentication, but we would not recommend it.

Events – The events tab configures how the camera senses activity/events and responds to them.  Notable features are face detection (which worked rather well), and motion detection/video analytics which also worked well and was easy to configure.  However, the event triggers seemed to be limited to the camera only, meaning you could trip an alarm output (DO), record to SD/SDHC, or send video via email or FTP.  There did not appear to be any methods to send logical alarm event outputs to the NVR or VMS, leaving most of these features best residing on the head end software platform for most applications.   We should also note however, that while we are aware an SDK from Samsung that would likely allow for passing logical video alarm events exists, we also have not asked the manufacturer for relevant information about it and have not verified integration with other NVR manufacturers about compatibility.   We also noted that NAS support is available, and alarm events can trigger automatic recording to the NAS device, although this feature was not tested.

Camera Setup – Multiple profiles are supported, with backlight compensation, WDR, AWB, and day/night modes all worked well in our testing under different lighting conditions.  We were unable to find a way to export/import camera profile settings however, and feel that for an enterprise installation, a shared profile among cameras that could be imported during installation would make installations easier and more uniform.

Focus Setup – Focus/Zoom was configurable by a joystick switch on the camera body itself, and via software in the configuration menu.  It was less than intuitive however, and the “Simple Focus” feature really didn’t seem to help set a specific field of view as we’d hoped.  For a varifocal camera, we expected to be able to set the view and autofocus would take care of itself.  We also were unable to remotely zoom via our NVR software, even though it detected OXML PTZ control via ONVIF.

Setup for NVRs

Note the URL for RTSP viewing from your NVR, if not automatically configured via ONVIF, would be “/profile2/media.smp”.  At least that’s what worked in our testing.  Our VMS software did not correctly identify the ONVIF RTSP URL, and we had to input the string manually.  The correct URL was not documented in the setup instructions as best we could determine.

Also on the camera setup page under “Video Profile”, the ‘profile’ setting may need to be changed from “High” to “Baseline” for some NVRs, in order to work properly.  Other settings, FPS, resolution, codec, bitrate, etc. should be changed as suitable.

Summary

Overall the build quality and features of the Samsung SND-7084R are very good.  We found most of the built in software features easy to use and effective, and image quality and stability was excellent.  Warranty for the camera is 3 years.  We feel this camera is suitable for commercial and government installations, and depending upon the video management system, could be suitable for enterprise installations that could take advantage of it’s embedded video analytics.

DSCN1018

 

 

 

 

 

 

 

 

 

Posted in: Reviews

Leave a Comment (0) →

Product Review – Wansview NCM-623W Wireless IP Camera

One of the things we do as a service to our customers here at Protective Resources is product reviews.   We even have manufacturers request that we test and review their product for bugs or suitability to a given mission profile.  Mostly this is fun for us.  We get to see new toys and try to break them, often learning something ourselves along the way.  In this case we were testing Network Video Recorder (NVR) platforms and I needed several IP cameras to serve as video feeds for the NVRs.

For the first product review of this particular blog, I thought I’d do a simple one for a really cheap, but powerful IP camera that I’ve used for testing and demonstrations.  This camera is a Chinese import product that is most likely NOT on the approved manufacturer’s list for most commercial grade NVRs.   That’s where this product comes in.

The Wansview NCM-623W Wireless IP Camera is not, in my opinion, a robust commercial grade IP camera that I would recommend to a client for use in an administration or R&D type facility.  The product looks like it is more suited for home or retail use, as it’s on the lower end for resolution (1MP) for an IP camera.  It is however, a very solid built and reliable camera with some pretty nice features for the price.  For a camera that I paid $138.00 each for, I really can’t be upset about any of the the “cons” that I’ve discovered with this camera.   It’s been over a year or so now, and there may be other products on the market that are comparable, but for the price and ease of configuration, I’m satisfied with my purchase of these cameras for demonstrations and evaluations.

Some Specs:

wansview NCB-546W

Wansview NCM-623W Wireless IP Camera

  • 1280 x 720 Max Resolution (1 Megapixel) at up to 30fps and 4mbps bitrate.
  • Lens f=3.6mm, F=2.0
  • VGA/QVGA/QQVGA three video resolutions optional.
  • RTSP and ONVIF compatible
  • Motion detection can detect environmental situation.
  • Built-in Microphone, supports two-way intercom function. (G.711/G.726 Codecs)
  • 10/100 10baseT, or 802.11b/g/n wireless protocol.
  • Supports UPNP, Motion detection, Infrared LED for night vision (up to 5M)
  • Support for mobile phone
  • Supports TF Card for on camera recording (event or continuous)

 

We successfully connected this camera to several NVR software platforms using RTSP at full resolution and bitrate.  It performs well, but it is definitely strained.  It has a built in webserver, and connecting to it while it’s streaming at that rate is, well, sluggish.  The default user “admin” and password “123456” are  used to login (and connect via the RTSP stream if you don’t change it, which you did, right?).  There are actually three users by default, “admin”, “user” and “guest”, all with default passwords that should be changed.  As far as I know, these can only be changed by the web interface, and there is no enterprise type remote configuration tool.

Once connected as admin you can configure the camera settings, users, recording features, alarm features, wireless features, and network settings like FTP, DDNS, and email upon alarm events.  It has a pretty rich feature set for the price.  The audio worked well using either codec to an Internet Explorer browser (not Firefox or Chrome), but only when connected via hardwire ethernet.  When using wireless ethernet the audio is choppy, and changing codecs, bit rates, or wireless network protocols did not solve the  problem.  The camera supports G.711 and G.726 audio encoding format. The sound of the G.711 is better, but it takes up more bandwidth.  Using the G.726 codec didn’t make any difference over WiFi.  An email to Wansview tech support has never been answered.

Since it supports both MJPEG and RTSP streams, you can connect to it with most any IP Camera NVR software or even a desktop media player like VLC.  The syntax for the RTSP stream is a little cryptic, but the high resolution stream I found best was something like this:  “rtsp://admin:123456@camera251.myip.com/11”, but each of the streams may be connected to as follows:

  1. rtsp://user:pass@ip:port/11 (View the first video stream – 1280×720)
  2. rtsp://user:pass@ip:port/12 (View the second video stream – 640×360)
  3. rtsp://user:pass@ip:port/13 (View the third video stream – 320×180)

Video quality and picture resolution was quite good, as you can see from the test image.   The video is 1280X720 @ 512kbps data rate and 15 fps.

Wansview Demo Picture

Overall we are pleased with this camera.  If you have sufficient experience with network IP cameras and NVR software, and understand the jargon and technical issues, this camera is worth the money and will do the job.  It’s not going to replace a $500 Axis IP camera, but then it only costs 1/4 the price too.  For our purposes, this camera performs well, is cheap enough we can buy enough to fully test an evaluation NVR, and supports enough modern features that we can put a demo through its paces and see how it performs without having to worry about the field hardware.

Pros

  • Inexpensive
  • 1.3 Megapixel @ 30 FPS and 4mbps Data Rate
  • IR LED Illuminator
  • Two way Audio Hardwire
  • Ethernet or 802.11 G/N Wifi
  • RTSP or MJPEG Streams
  • Web Interface or Smartphone Client
  • Email / FTP / Local Recording

Cons

  • Audio Over WiFi Unreliable
  • Some Software Features a Little Buggy
  • “Shutter” click sound audible when ambient light changes
  • Web Interface Slow
  • Documentation Lacking

 

 

Posted in: Reviews

Leave a Comment (0) →

Facial Recognition for Access Control?

Several years ago,  I worked on a project prototype for a major group of sea ports that had an interest to use the state’s drivers license image database for facial recognition/verification of TWIC applicants and the eventual use for identity verification for critical card access points.  The main focus of the project was to ensure that the person applying for the TWIC card was indeed who they claimed to be, and not an imposter.   Neither the CCTV system nor the card access system had the built in software to do this, much less do it together, so we had to write the interface and the software to manage it.  It worked, but not as well as we would have liked.   We used a GPL’d algorithm for the facial recognition, which while good, would have some false positives and false negatives from time to time.   Ultimately to me, it served as a proof of concept.  It did work, and could be made as a serviceable monitoring and investigation tool for security.  (Later we used that same GPL software to create a tool that would scrounge through the card access database and crop the cardholder photos to a uniform size.  THAT worked really well.)

Years later, as far as I know there is still not an off-the-shelf system that provides a true facial recognition monitoring capability for access control violations.  This seems like something very straightforward to do, and as most companies or government branches have an actively maintained photo database of their cardholder personnel, and most often have video cameras monitoring locations where access control is used.

The biggest limitation we found was the quality of the CCTV images against the badge database photos.   Both were of rather poor quality, but if we used the software as just a pre-filtering tool for security operators, the margins of error were more tolerable.  The idea was to still have a security guard doing the verification, but not for every photo, just the ones the software couldn’t handle well.

Cardholder with back to camera.

Poor camera angle doesn’t allow for good facial recognition

With Megapixel IP cameras replacing low resolution analog cameras, the probability improves of having a photo with an acceptable number of unique data points to match against an image database with a high degree of confidence.  This means more information data points to compare, and fewer false positives and negatives.   There are still other considerations such as angle of view, proper lensing, lighting, face concealment/alteration issues, and image database accuracy.  And you must have most, if not all of these considerations to have a usable image.  As shown here, even if you have good lighting and resolution, if you don’t have a good angle and lensing, you will not have a usable image for facial recognition of the cardholder.

Currently, there are about a dozen corporations world wide that offer some type of facial recognition software.   Many of their larger customers are government agencies or the financial industry.  It is used in some border crossings, passport identification, and high profile monuments.   The FBI may be the most famous consumer of this technology, but it is not used in a widespread fashion as far as I know.  Naturally, this isn’t something that is widely advertised by these agencies.

Still, as such a highly technically savvy country as the USA supposedly is, I’ve often wondered why we don’t have facial recognition with a national database at all critical locations like border crossings, airports, bus stations, train stations, embassies, and hospitals.  I realize there’s a modest invasion of privacy, and nobody likes the thought of having “big brother” monitor your whereabouts, especially putting your name to your face in a specific location and time.   It’s kind of creepy.  But the other side of the coin is that if we maintain a central photographic database of active criminals and terrorists (which we do), then having feeds from certain cameras in certain high traffic locations might allow us to not only apprehend said criminals/terrorists in a timely manner, but even allow us to gain intelligence regarding their commuting patterns, associations, and personal habits.  This is beneficial information that can reduce crime and terrorism.

Keep in mind, the government already has a very large database of photos, probably including you, even if you don’t have a mug shot in the NCIC.  Facebook, Twitter, Instagram, LinkedIn, are all repositories available that most likely link your face with your name.   The FBI has said that by 2015, it plans to have 52 million photos in its NGI facial recognition database.   The FBI will include non-criminal information as well as criminal.  Where’d they get those?!    So, you may already be in the database, and maybe me too.  Obviously, some people will object to this idea, some even quite profusely.  But the genie is already out of the bottle.  Getting him stuffed back in is going to be difficult, if not impossible.

So the natural progression on this “big brother” concern just may be to license the database.   For a fee, allow vetted customers to have access to the database via an API to use this centralized database for government and limited private commercial purposes.  Want to know if your daughter or son is in the NGI database?  Maybe there’s a background check service company that can tell you.   But for financial institutions, or the port authority I mentioned in the beginning of this article, it would be a boon of intelligence data.   Not only would they have their own employees and contractors in their own database, they could also have access to a national database of “persons of interest” that could assist them in determining if a potential applicant is a criminal, or maybe even just a high risk.  That has the simultaneous possibility of reducing their own risks, and providing timely information to Homeland Security about a potential threats whereabouts and possible intentions.

Facial recognition of employees at work

Facial recognition in the workplace.

I think the future of this technology is already headed in this direction, and there may already be entities that are doing exactly what I’ve described, but I believe the technology will become more pervasive as some of the technological (and sociological) barriers are broken down.

Posted in: Access Control, Company News, Security Technology

Leave a Comment (0) →

Digital Video Forensics: “Is this video clip reliable?”

When we receive a request from an attorney or a forensic engineer to review digital video material, we are most often asked, “Is this video clip reliable?” Over the years, we’ve learned that this can mean many different things. The material in question is often a short piece of video in the form of a digital file that can be played using common media players, such as Windows Media Player. In some cases, the material is accompanied by proprietary viewer software that is required to view the video. On occasion, the video is actually in a DVD format, complete with title and menu.

But what our clients really want to know is one or more of the following:

“Is this video clip a true and complete copy of the original?”

“Has this video clip been altered or edited?”

“Can I rely on the time and date that appear in the video? To what degree of precision?”

“Are the proportions of the picture correct? Can I use it to measure distances?”

We generally deal with civil cases and not criminal investigations. In a criminal investigation, it is usually enough for investigators to obtain identification from the video. This may be facial identification of a perpetrator, the approximate height and weight of the individual, or simply a general description of the clothing the perpetrator was wearing. In some cases, investigators seek to identify a vehicle, by model, make, or color. The investigating agency may extract important images for enhancement or to distribute in aid to the investigation. But it is very rare that a criminal investigator concerns himself or herself with the precision of the date and time stamp, or whether a single frame may be missing from the video sequence.

In civil lawsuits, it is a different matter. Unsurprisingly (and according to the “CSI” shows), video recording systems are everywhere and frequently record video of incidents unintentionally. We have, for example, worked with numerous video files from security systems that recorded vehicle accidents in the background, a purpose for which they were not originally designed or installed. A civil lawsuit in connection with the accident might require the involvement of forensic engineers, who will normally perform a survey of the accident site to obtain accurate measurements of the positions of the vehicles before, during, and after the accident. Since vehicle speed may be a contributing factor in an accident, the engineers want to estimate the vehicle speed(s) at different locations. Speed is often estimated on the basis of skid marks or the amount of damage sustained by the vehicle(s), but the availability of recorded video gives the forensic engineer the opportunity to estimate vehicle speed by time interval. Knowing that speed=distance/elapsed time, and having accurately measured vehicle position during the investigation, all we need is a precise measure of the time interval between the frames of the video clip that show the vehicle at those measured positions. What could be simpler?

As it turns out, a lot. Most digital video recording systems were never intended to be used to measure time intervals to the precision required to differentiate between a vehicle going 45 MPH in a 45 MPH zone and a vehicle going 56 MPH in a 45 MPH zone. In fact, most date and time stamps inserted in video recording systems do not display with any more accuracy than one-second intervals, though some may display to a greater precision. If we do have a system with sufficient precision, there may then be the question of accuracy. Being precise to the millisecond is one thing. Being accurate is another. The task is further complicated if the video clip has been exported by the video recording system in a format different from that which was used in the original recording. It is very common for a video recording system that uses variable frame rate (i.e., the intervals between successive frames are not uniform) to export video clips to a video file format that uses a constant frame rate. The exported files are quite useful for identification purposes, but may useless for performing the calculations required to accurately estimate vehicle speed.

We frequently receive video clips in which the date and time stamp advances 15 minutes, or some other fixed time period, but the video clip actually plays in much less time using a software media player. We have several clips in which the audio portion of the file is shorter than the video itself, sometimes by more than 10%. The questions are then, “Which time intervals are correct? Can we state with confidence that the actual time interval between the vehicle at this location and that location is X.X seconds? What is our confidence interval for our estimate?”

Strangely, old-fashioned videocassette recorders are often more reliable and useful for the purpose of estimating time intervals than are modern digital video recording systems. A standard VHS recorder was designed to record video at 29.97 frames per second, and we have the further advantage of knowing that the camera was providing video to the recorder at an identical rate. Newer IP video cameras and digital recording systems normally work with variable frame rates and may even add the time stamp to the images only after they have been received at the recording unit, adding the problem of network latency to the mix.

A gentleman who was very experienced with digital video and had worked for years in the industry once told me that he would, “…never try to estimate time intervals in digital video with BOTH precision and accuracy.” While this might be an extreme view, it certainly reflects the challenges that face us.

We have attempted in this article to identify some of the important considerations in establishing the “reliability” of digital video used in forensic accident investigation. In subsequent articles, we will discuss some of these topics in more detail and introduce new topics of interest.

Posted in: Expert Witness, Security Technology, Video Forensics

Leave a Comment (0) →

Training Class – Preparing for the North Carolina SP-FA/LV Electrical Examination

Protective Resources is the premier provider of training for individuals who are planning to take the North Carolina Board of Examiners of Electrical Contractor SP-FA/LV examination. Our one-day class, “Preparing for the North Carolina SP-FA/LV Electrical Examination,” is a proven method for applicants to learn about the exam and to review the major topics it covers. We have classroom exercises that emphasize using the exam references, including many charts and tables, to derive the correct exam answers.

We are currently scheduled to present this class on the following schedule:

  • January 28, 2015                  ADI, Greensboro, NC
  • March 25, 2015                     ADI, Raleigh, NC
  • May 27, 2015                         ADI, Raleigh, NC
  • July 29, 2015                         ADI, Greensboro, NC

We are also happy to provide a quotation on presenting private class sessions for two or more students. If you are planning on sending two or more students to our regular class, it may be more economical to have us bring the class to you.  We are also able to offer coaching sessions, if you think you need more personalized help to ensure being successful.

Contact us at training@protectiveresources.com for more information.

Posted in: Training

Leave a Comment (0) →

Digital Video Forensics: Analog and IP Video Cameras

While time-lapse video recorders (TLR) using videocassettes remain in use in many smaller video surveillance systems, digital video recorders (DVR) and network video recorders (NVR) continue to be the preferred choice for larger and more complex systems. The video cameras that provide the images to these recording systems may be either analog or IP (internet protocol). For TLRs, analog cameras are almost invariably required, though it is technically possible to use IP cameras in a TLR system. For DVRs and NVRs, either analog or IP cameras, or a mixture of the two types, may be used. For the purpose of video forensics, knowing the type of camera that originally captured the video is critical to an understanding of several important aspects of the video material to be examined.

In North America, analog video cameras are almost certain to be compliant with the NTSC video system. (In other parts of the world, cameras may comply with PAL, SECAM, or other video system standards, which differ from NTSC in many crucial aspects. For the purpose of this discussion, we shall limit ourselves to the NTSC system.) The NTSC (National Television System Committee) standards for video systems were developed primarily to ensure the compatibility of broadcast television signals with consumer television sets.  The first standard was published in 1941, with subsequent revisions to accommodate advances such as color TV, and all of the standards are readily available from many sources for reference purposes.  The NTSC system standard is perhaps most important because it describes the way in which a video image is created on the “old-fashioned” CRT (cathode ray tube) television sets we used for well over 50 years. It should come as no surprise that analog video surveillance cameras of that period were designed and manufactured to provide a video picture that would display in an identical manner on video monitors using CRTs. Therefore, we can safely assume that an analog NTSC camera produces a signal that complies with the relevant sections of the NTSC standards.

Why is it important for a video forensics analyst to know if video material originated from an NTSC camera? Regardless of the method used to transmit and record the video images, the use of an analog NTSC camera places certain limitations and restrictions on the original video source and, consequently, on the recorded video images. We are frequently presented with digital video files that are known to have originated from an NTSC camera and, in many cases, can point to attributes of the video images that are inconsistent with an NTSC source. In some cases, there are anomalies that can be readily explained in no other way. In the following paragraphs, we will discuss a few of the most relevant features of the NTSC video system and the analog video cameras that employ it.

First, the aspect ratio of an NTSC video image is 1.33, or 4 units (wide) by 3 units (high). This aspect ratio is specified by the NTSC standards, but may vary slightly from system to system through minor variations in CRT scanning or other equipment variations. However, a DVR that produces a video file that is 720 pixels (wide) by 480 pixels (high) from an analog NTSC camera is either substantially distorting the image or cutting off portions of the image when recording since the aspect ratio of the digital video is 1.5 and definitely not 1.33. This is a common problem and once that we see in many cases.

Second, the standard frame rate for NTSC video is 29.97 frames per second. A new frame (complete image) is presented from the camera to the recorder every 33.4 milliseconds on a continuous basis. The consequences of this fixed, predictable frame rate can make a dramatic difference if the purpose of the analysis is to ascertain the exact time interval between any two frames in the digital video material. Since accurate and reliable time intervals are critical to establishing such basic data as the velocity of vehicles or other moving objects shown in the video, we are often asked to render an opinion on this specific aspect of the material. We will discuss this topic in more detail in a subsequent post. Ironically, “old-fashioned” videocassette recorders are often much better at providing accurate and reliable time interval measurements, as they were originally designed to record and play back video at precisely the same rate at which it was recorded (29.97 frames per second).

Third, NTSC video images are interlaced and each frame actually consists of two separate fields. A CRT monitor creates a visible image by scanning an electron beam horizontally across the inside face of the tube. The electron beam, guided by a strong magnetic field, starts at one side of the tube and scans to the other, then returns to the starting side and scans another line below the first.   This continues until the entire face of the tube has been scanned from top to bottom, creating a visible image. During the development of consumer television, it was discovered that creating an entire image every 33 milliseconds was not fast enough to prevent a noticeable and objectionable lag when objects in the image are moving. To compensate, the NTSC standards require that the electron beam scans the odd-numbered lines of an image and then returns to scan the even-numbered lines, thus requiring two complete scans of the screen to create what is a single interlaced frame. (Scanning just the odd or even-numbered lines is called a “field.” It takes two fields to create a frame. A single field takes approximately 16.7 milliseconds to create.) When a DVR or NVR records an analog camera, it must employ some technical method to convert the interlaced video signal to a digital video format, most of which are not interlaced. (A video image that is not interlaced is called “progressive.”) Some digital systems simply ignore one of the fields, recording just the odd or even-numbered field as if it was a complete frame. Other systems may combine both fields into a single progressive image. Each method creates slight anomalies that may have an impact on video analysis.

Fourth, NTSC video images are composed of discrete horizontal lines, but the horizontal lines themselves are continuously variable from side to side. A complete video image requires 525 horizontal lines to create (262.5 per field). Of these, only 483 lines are actually visible. The remainder are used for timing and control purposes and do not normally appear on the visible portion of the CRT screen. (Early closed captioning for broadcast television embedded the caption information in the non-visible lines.) Therefore, the maximum number of discrete picture elements in the vertical portion of an NTSC video image is limited to 483. Any other number of vertical elements is a result of interpolation by the recording device, or by omitting one of the fields (see paragraph above). The horizontal scan lines themselves do not have discrete elements. The intensity of the electron beam that scans the inside of the CRT varies continuously over a fixed range as it moves from one side to the other. (Other techniques are employed to render color.) Since the signal varies continuously, there is no standard number of picture elements specified by NTSC for the horizontal dimension. The ability of a specific camera or monitor to resolve in the horizontal dimension is normally measured by the number of vertical lines it can successfully display on the screen. Both video cameras and CRT monitors vary tremendously in the number of vertical lines they can produce or display. It is not at all unusual for a system to have cameras which are only capable of producing a video image of fewer than 360 vertical lines connected to high-quality CRT monitors that can display more than 525 vertical lines. Again, understanding and interpreting the implications of the way in which NTSC video images are created plays an important part when reviewing digital video material.

So far, we have discussed analog NTSC cameras exclusively. We will now turn our attention to IP video cameras.

Many consumers confuse digital video cameras with IP video cameras. Some analog NTSC video cameras use digital technology to capture and process video images, and these cameras can certainly be considered to be digital. However, the video is then converted to NTSC standards to be transmitted on coaxial cable, twisted pairs, or some other transmission media. The conversion to an NTSC signal necessarily means that the video is then subject to the NTSC requirements discussed in previous paragraphs. IP video cameras do not comply with NTSC standards, though some units may simultaneously provide both an IP and an NTSC output.

IP video cameras transmit video images to the recording device using the internet protocol. At the most basic level, this requires the image to be digitized (or “encoded”) and then converted into data packets that can be transmitted over a data network. The variety of methods for digitizing and transmitting video from a camera are far too numerous to describe in this paper, so we will limit ourselves to describing some of the key differences between IP cameras and NTSC cameras.

Unlike cameras that comply with NTSC standards, IP cameras are not required to provide video at a standard, uniform frame rate. (When dealing with digital video, many analysts prefer to use the terms “image rate” or “images per second,” rather than “frame rate” or “frames per second.” For the purposes of this paper and to make comparison easier, we will use the “frame” terminology for both types of camera.) There are two major reasons for this: First, most IP cameras can be programmed to provide individual frames either at specified intervals or upon request. This prevents overloading the data network by transmitting video data that are not needed or cannot be recorded by the system. Second, digitized video is often encoded using methods that permit variable frame rates. For example, many MPEG-4 encoding methods embed information on the presentation time of an individual image and the length of time that it should be shown on the display monitor. This is in sharp contrast to the NTSC system, where video frames are presented continuously and at fixed intervals. As a consequence, it can be extremely difficult to ascertain the actual time interval between two events (or frames) in a digitized video sequence unless we have extremely high confidence in both the camera and the recording system.

Another major difference between NTSC systems and IP systems is that the aspect ratio of the images may vary significantly depending on the equipment used and the recording settings. It is not unusual for an IP camera to transmit video images with one aspect ratio (for example, 1.5, or 720 pixels by 480 pixels) that is subsequently altered either in recording or when it is played back on a monitor. This is further complicated for both NTSC and IP cameras by the fact that individual pixels on NTSC monitors are of a slightly different shape than those found on most computer monitors. Ascertaining exactly what aspect ratio the original image had can be very challenging, but critical for measuring the velocity or position of moving objects.

Finally, the digitizing process that encodes the digital video at the camera can introduce some significant anomalies. Because of technical limitations and the desire to reduce bandwidth usage on the data network, many decisions have to be made about the acceptable frame rate, image size, and image quality for any individual IP camera. (This is also a major consideration when the video signal from an NTSC camera has been digitized for recording or transmission.) The encoding process that digitizes and compresses the video images necessarily introduces artifacts and anomalies into the images. Perhaps the best known and most easily recognized artifact is macroblocking, the appearance of block-like structures in some portions of the video image. But there are a number of other characteristics of the encoding process that can produce more subtle alterations in the image that are easily missed by the typical viewer.

This is not to say that IP video cameras are inferior to NTSC video cameras. One area in which IP video cameras excel is image resolution. It would not be possible, for example, to transmit video images with megapixel resolution using NTSC technology. As we have seen, there are hard limits on the number of horizontal lines in an NTSC signal and even economical IP video cameras far exceed these limits by producing images with two and three times this vertical resolution limit. There are excellent reasons for users to select video surveillance systems that use modern IP cameras.

We have attempted in this paper to identify some of the important characteristics that distinguish NTSC video cameras from IP video cameras and to describe the importance of identifying which type of camera was used to create a digital video file that is subject to analysis. In subsequent papers, we will discuss some of these topics in more detail and introduce new topics of interest.

Posted in: Video Forensics

Leave a Comment (0) →
Page 4 of 5 12345